Adding processing support for the mSBC codec is somewhat problematic,
because, although it is a SBC codec, the a2dp handling can't simply be
reused because the codec is used on an eSCO link with transparent
data, meaning the transmission unit has to be 48 bytes (fragmenting
the codec packets) and reassembly and boundary detection is required
to be done by the implementation. Therefore we have to implement
separate render and push routines for msbc that do this fragmentation.
Fragmentation is done by emulating circular buffers. The receive
(push) buffer is easy, since the mSBC packet size is 60, simply have a
buffer of this size in the sbc_info area where the fragments are
reassembled. Once we have a full 60 bytes, decode and restart from
zero. The send (render) buffer is more problematic, since the
transmit must be done from contiguous memory. This means that the
buffer must be the lowest common multiple of the transmission unit and
the packet size. This value is 240 since 240/48 == 5 and 240/60 == 4.
So the buffer pointers are reset at 240 which is a whole number of
both rendered packets and eSCO transmission units.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/507>
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: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/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: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
Instead of letting a codec with higher index have higher priority,
just use a lower index for high priority. This allows the for loop
iterating over the codecs to be written in a straightforward manner
and not have to iterate from the end. FWIW Pipewire does the same.
Part-of: <https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/440>
This patch introduce new modular API for bluetooth A2DP codecs. Its
benefits are:
* bluez5-util and module-bluez5-device does not contain any codec specific
code, they are codec independent.
* For adding new A2DP codec it is needed just to adjust one table in
a2dp-codec-util.c file. All codec specific functions are in separate
codec file.
* Support for backchannel (microphone voice). Some A2DP codecs (like
FastStream or aptX Low Latency) are bi-directional and can be used for
both music playback and audio call.
* Support for more configurations per codec. This allows to implement low
quality mode of some codec together with high quality.
Current SBC codec implementation was moved from bluez5-util and
module-bluez5-device to its own file and converted to this new A2DP API.
