[pulseaudio-discuss] Bluetooth aptX codec
pali.rohar at gmail.com
Sat Jul 7 08:30:43 UTC 2018
On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote:
> > This is a good idea to let external service to do codec-specific
> > functions... I agree that it simplify pulseaudio code and other things
> > (like proving new codec by external library -- if properly implemented),
> > but in bluetooth context we should look at questions:
> > 1) Has gstreamer support for SBC codec?
> > 2) Has gstreamer support for aptX codec?
> > These are two major codecs supported by bluetooth headsets.
> > Answer is: NO
> > (SBC is now provided in the "bad" set which is not pre-installed by
> > gstreamer)
> Pre-installed doesn't mean much tbh. It is easy enough for packages to depend on it.
Can pulseaudio build process enforce it?
> > So gstreamer in current state is not very useful for pulseaudio.
> Writing a plugin around an existing decoder is pretty trivial. As is exposing libav/ffmpeg codecs.
> > Important are also MPEG1/2 (which are defined as optional by A2DP)
> > and also AAC and LDAC which Jan wrote. But gstreamer has again only
> > plugins in "bad" and "ugly" sets for them; nothing preinstalled by
> > default.
> Again, -bad doesn't mean much in the current day (historically it was a staging ground). -ugly is for codecs that are known to be patent-encumbered (and how that's made available is up to packagers).
Still more distributions does not compile ffmpeg with all codecs due to
So there is a high chance that we end up in situation that pulseaudio
would not be able to encode audio into codec X (even pulseaudio declare
that it support) and user would not be able to do nothing as his
distribution does not enabled codec X at compile time. It could be
really a legal problem or problem because packager forgot to enable it
or because he think that it could be a problem and rather disabled it.
The only option to prevent such situation is compile time check. Like
now pulseaudio does not compile bluetooth support when sbc codec is not
available. And this check should be there even after moving to
ffmpeg/gstreamer/whatever. So is this check possible to write in
autoconf for that ffmpeg/gstreamer/whatever?
> > To have working bluetooth support in pulseadio, pulseaudio needs to use
> > external library for encoding which *always* provides support for SBC.
> > And not only if user manually installs some special plugin for 3rd party
> > library. (And not only SBC, but also those other aptX, MPEG1/2, AAC and
> > LDAC codecs)
> So I continue to disagree. Using a generic framework and letting other parts of the system select the codec implementation is what makes sense for the widest set of use-cases (this also allows products to ship their own implementations of a codec without changing the PulseAudio code).
Still this is not enough for bluetooth codec. For specific codec you
need to create bluez dbus endpoint with codec specific parameters. Plus
implement select and set methods to decide on codec parameters between
pulseaudio and bluetooth headset. And finally to send encoded data you
need to know how to send them. To which endpoint, how header looks like
etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must not
have RTP (e.g. aptX). And after that comes data from codec encoder
So is there any library which all above support? I have not find
anything. Nor ffmpeg nor gstreamer.
Which means that pulseaudio cannot delegate codec selection, codec
initialization and codec encoding to some external library (yet).
Anyway, now in bluez source code is some kind of codec encoding support
for android systems. Therefore should not be a wise idea to move all
these codec A2DP mess into bluez source code? Because now part of A2DP
is in bluez and another part in pulseaudio. And on android is everything
in bluez now.
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the pulseaudio-discuss