GitLab

A pipeline is effectively a bin, with all kinds of (currently unused)
bits attached.

This causes pretty verbose logs otherwise, and is unnecessarily
expensive.

The encoding and decoding pipeline are essentially identical: both push
data in via an appsrc, route it through a codec-specific (opaque)
element, and finally pull data out of an appsink. The code already makes
it impossible to have an encoding and decoding pipeline simultaneously
set up in `gst_info`, and converting `bool for_encoding` to a tri-state
(encode, decode, or both) would be messy; particularly when encoding and
decoding could possibly differ in format.

This change removes a swath of code and removes the possibility of
misusing `enc_` or `dec_` in the wrong place (ie. after copying a bit of
code and forgetting to rename one or two). When bidirectional codecs
come online a second codec instance (`gst_info`) can simply be created
and controlled independently.

Part-of: <pulseaudio/pulseaudio!487>

For consistency with its decode_buffer counterpart.

For the time being the base function only performs an extra check and
logs an error when no data has been written into the GStreamer encoding
pipeline.

Part-of: <pulseaudio/pulseaudio!487>

Fixes: 73c80ffb ("bluetooth/aptx: Deduplicate caps setup for encoding and decoding")
Part-of: <pulseaudio/pulseaudio!487>

Part-of: <pulseaudio/pulseaudio!476>

Desired SBC bitpool value is calculated from target bitrate limit.

Part-of: <pulseaudio/pulseaudio!476>

Fixes: 96995112 ("bluetooth: allow increasing output bitrate")
Part-of: <pulseaudio/pulseaudio!477>

Part-of: <pulseaudio/pulseaudio!477>

While cleaning up the BlueZ counterpart of strings defined in
preprocessor macros it is only consistent to take care of all DBUS_
macros as a whole.

Part-of: <pulseaudio/pulseaudio!477>

These errors and interface names shoudld all reuse predefined constants.

Part-of: <pulseaudio/pulseaudio!477>

Define all BLUEZ_ macros once in the shared header, instead of twice in
both backend-native.c and bluez5-util.h.

Part-of: <pulseaudio/pulseaudio!477>

Consistently use newlines and the same indentation style for all calls
to dbus_message_iter_open_container in Bluetooth code.

Part-of: <pulseaudio/pulseaudio!477>

The null-source did not change max_rewind when changing the latency. This
patch fixes the issue.

Part-of: <pulseaudio/pulseaudio!493>

Unlinking the monitor source after unlinking the sink leads to a crash when the monitor
source is master of a virtual source. Changing the unlink order fixes the problem.

Part-of: <!493>

The plug: ALSA PCM device name can pass any device name
even with argument, but the syntax is:

plug:SLAVE='<pcm_device_name>'

BugLink: https://github.com/alsa-project/alsa-ucm-conf/pull/75#issuecomment-768555182Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Part-of: <!492>

Part-of: <pulseaudio/pulseaudio!488>

LDAC encoder already supports S16, S24, S32 and F32LE. Using FLOAT32LE
for the sample format would avoid the additional call for conversion to
pa_sconv_s32le_from_float32ne. perf tool shows this as being the function
called frequently after encode. So, just avoid this by using sample format
as F32LE.

Part-of: <pulseaudio/pulseaudio!486>

Now that codec-specific code only touches its own bin and not any
elements (appsink/src) outside of it, make things official by
initializng them later in gst_codec_init where they are actually needed.

Part-of: <pulseaudio/pulseaudio!484>

Make the codec-specific initializer more generic by not touching any
elements outside of its own GstBin.

Part-of: <pulseaudio/pulseaudio!484>

Part-of: <pulseaudio/pulseaudio!484>

Make the code ever so slightly more generic by not using appsrc and
appsink in codec-specific logic when assigning caps specific to the raw
(PCM) format provided by or returned to PA.

Note that caps have to be set (= event) after starting, can't send
events in flushing state.

Part-of: <pulseaudio/pulseaudio!484>

Part-of: <pulseaudio/pulseaudio!484>

Part-of: <pulseaudio/pulseaudio!485>

Currently translated at 95.1% (472 of 496 strings)

Translation: pulseaudio/pulseaudio
Translate-URL: https://translate.fedoraproject.org/projects/pulseaudio/pulseaudio/fi/
Part-of: <pulseaudio/pulseaudio!485>

Currently translated at 94.9% (471 of 496 strings)

Translation: pulseaudio/pulseaudio
Translate-URL: https://translate.fedoraproject.org/projects/pulseaudio/pulseaudio/fi/
Part-of: <pulseaudio/pulseaudio!485>

SBC codec decrements bitpool value by fixed amount each time it is asked to
reduce output bitrate. This results in reduced audio quality with SBC codec.

Implement increase_encoder_bitrate for SBC codec by adding 1 to bitpool value
each time encoder bitrate needs to be increased to restore SBC audio quality.
While at it, remove bitpool decrement limit to use connection agreed value
instead as we will be able to restore quality later.

Part-of: <pulseaudio/pulseaudio!474>

Bluetooth thread may ask encoder to reduce bitrate if writing is not keeping up
with inputs or writing to bluetooth socket takes too much time.

Assuming conditions leading to reduced bitrate are intermittent, allow periodic
attempts to increase encoder bitrate, by default at most twice per second.

Part-of: <pulseaudio/pulseaudio!481>

Part-of: <pulseaudio/pulseaudio!479>

As suggested in [1]:

This way it is possible for a codec to have both the encoding and
decoding part optional, instead of getting both or nothing (where PA
theoretically supports both).

In addition this cleans up code that was previously checking the
existence of a function pointer, or nothing at all (switch_codec).

[1]: pulseaudio/pulseaudio!440 (comment 768146)

Part-of: <pulseaudio/pulseaudio!479>

In cases, where codec initialisation may fail, we still try
unregistering the message handler. Do not try unregistering
the handler if it was not registered in the first place.

Part-of: <pulseaudio/pulseaudio!483>

Part-of: <!475>

Similar to the situation/comment in `endpoint_release` BlueZ does not
request any reply to `ClearConfiguration()` either; sending one results
in the same "0 matched rules" warning from dbus-daemon:

    dbus-daemon[1309]: [system] Rejected send message, 0 matched rules; type="method_return", sender=":1.71" (uid=1000 pid=87548 comm="../build/src/daemon/pulseaudio -vvvv -n -F ../buil") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.3" (uid=0 pid=1308 comm="/usr/lib/bluetooth/bluetoothd -d ")

Solve this by only creating a return message when an (othwise empty)
reply is solicited for, just like in `endpoint_release`.

Unfortunately we also have to make sure to not send any error back if no
reply is requested, but fortunately an argument parsing error here is
extremely unlikely.

Part-of: <pulseaudio/pulseaudio!472>

We move the codec specific bits to their own respective files and now
make the codec specific initialisation use a GstBin, which the generic
GStreamer module now uses in the pipeline.

It is job of the codec specific function to add elements in the GstBin
and link the added elements in the bin. It should also set up the ghost
pads as a GstBin has no pads of it's own and without which the bin
cannot be linked to the appsrc/appsink.

Also, we now only initialise either the encoding or the decoding
pipeline and not both. The codec init API already gets passed the
for_encoding flag. We pass and use the same to codec specific init
functions.

Part-of: <pulseaudio/pulseaudio!440>

As we now support codecs other than SBC, we might have codec which does
not have an encode or a decode capability. Specifically, in the case of
LDAC there isn't a known decoder implementation available. For such a
case, we should not register the corresponding endpoint.

In case of LDAC, as decoding cannot be supported, we should not register
a sink endpoint or vice versa in the other scenario.

To do this, we check if encode_buffer or decode_buffer entry for a codec
has been set in pa_a2dp_codec and accordingly prevent or allow it's
registration.

Part-of: <pulseaudio/pulseaudio!440>

Part-of: <pulseaudio/pulseaudio!440>

When it comes to codecs provided via GStreamer, we register all codecs
if GStreamer option is enabled for bluez5 via meson. However, the
GStreamer plugin required for the codec might not be present on the
system. This results in the codec being available for registration with
the bluez stack or selection by the user, but, trying to use the said
codec then fails.

To prevent the above, we now use the can_be_supported codec API to check
if the codec is usable and if not, we do not register the said codec and
also prevent users from switching to it.

Part-of: <pulseaudio/pulseaudio!440>

This API internally checks if a requested codec can be supported on the
system. This is especially required for codecs supported via GStreamer
where the availability of a plugin decides if the said codec can be
supported.

This will be used to prevent registration of a codec which the remote
endpoint device might be able to support, but, PulseAudio can't as the
codec is not available on the system due to the absence of a plugin.
We can also prevent listing or switching to an unavailable codec.

Note that the codec negotiation happens with the bluez stack even before
a device is connected. Because of this, we need to make sure that gst_init
is called before checking for the availability of a plugin. Since
module-bluez5-device gets loaded only after a connection to the device
has been established, doing the gst_init in that or one of the bluetooth
modules is not feasible.

Part-of: <pulseaudio/pulseaudio!440>