[pulseaudio-discuss] Bluetooth aptX codec

[Arun Raghavan]

On Thu, 21 Jun 2018, at 4:32 PM, Pali Rohár wrote:
> On Thursday 21 June 2018 05:45:39 Arun Raghavan wrote:
> > On Wed, 20 Jun 2018, at 9:05 PM, Jan Alexander Steffens wrote:
> > > On Mon, Jun 18, 2018, 09:42 Pali Rohár <pali.rohar at gmail.com> wrote:
> > > 
> > > > On Sunday 17 June 2018 23:48:42 Arun Raghavan wrote:
> > > > > On Sun, 17 Jun 2018, at 4:01 AM, Pali Rohár wrote:
> > > > > > Hi! As you may know lot of bluetooth headsets support not only SBC, but
> > > > > > also aptX codec. And new version of ffmpeg (4.0) has native aptX and
> > > > > > aptX HD encoder and decoder. AptX codec itself is proprietary, but
> > > > > > ffmpeg has clean-room implementation based on expired patent. What
> > > > about
> > > > > > adding support for aptX via ffmpeg into pulseaudio?
> > > > > >
> > > > > > --
> > > > >
> > > > > I'd actually like to delete the SBC code and replace it with a generic
> > > > GStreamer bin. That would allow us to be codec agnostic, and support any of
> > > > the codecs that are supported by GStreamer (which includes those that
> > > > ffmpeg provides).
> > > >
> > > > This does not sound like a good idea. The only two relevant bluetooth
> > > > codecs for most people are SBC and aptX.
> > > >
> > > 
> > > Don't forget AAC. I've seen this one a lot in devices meant for use with
> > > iPhones, which apparently don't have aptX. GStreamer has a lot of encoders
> > > for it so this shouldn't be a problem unless it's some strange AAC variant.
> > > 
> > > There's also LDAC but I haven't seen it on a device yet.
> > 
> > Right, there are multiple codecs that we can support, and we should not tie ourselves to a specific implementation. For this reason, and more generally, I'd like to have PulseAudio not have to deal with any codec implementations at all (nor even RTP, if we can help it), hence my preference to use something generic in the form of GStreamer.
> 
> 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.

> 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).

> 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).

-- Arun