[pulseaudio-discuss] Bluetooth aptX codec

[Pali Rohár]

On Wednesday 20 June 2018 17:40:09 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Mon, Jun 18, 2018 at 10:35 AM, 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.
> >
> > IIRC you cannot just choose arbitrary codec and use it in bluetooth, you
> > need to know how to put it into A2DP. Therefore for each bluetooth codec
> > you need to write some A2DP code or at least declarative definition. So
> > it would not work just adding dependency on gstreamer and let gstreamer
> > provide some encoded stream.
> 
> I guess we could limit to only codecs we know how to expose the
> capabilities, but note that it is possible to define vendor specific
> codecs in A2DP so in theory one can use other codecs like OPUS
> although it most likely won't have much use without the remote to also
> support them, but I guess it is a start.

Yes, it is possible to define vendor specific codes in A2DP, but then
only that "vendor" implementation would support that codec.

So if you define "pulseaudio" vendor codec, then only other instance of
pulseaudio on other A2DP would be able to use it. Which is not so much
useful.

> > And also we cannot ensure or force at compile time that users would have
> > installed both gstreamer and ffmpeg at runtime to have working bluetooth support.
> 
> We anyway register endpoints at runtime and if we cannot detect SBC
> for example we can still fallback to non-gstreamer/native mode.

That means we still need to have native (libsbc?) implementation in
pulseadio.

Then somebody can ask question: why we need to have support for
gstreamer's sbc, if pulseaudio has own native support? (no offense)

> > For me it looks like a overkill to add dependency on gstreamer to
> > pulseaudio, which would have some runtime dependency on ffmpeg to have
> > working bluetooth support. And it would work only with the last ffmpeg
> > version which is not widely available yet (and replacing system version
> > is not always trivial).
> >
> > Anyway, I would try to write simple aptX library based on published
> > details and ffmpeg source code. And try to play with pulseaudio if I
> > would be able to start streaming aptX to bluetooth headset. This is at
> > least good starting point to prove that aptX codec is usable or not in
> > pulseaudio.
> 
> Having native support won't be bad either but I think we need to have
> some module support added in order to make easier to add new codecs
> which should be useful if we ever come to integrate with gstreamer.

Module support in pulseaudio could be useful. But for every codec you
need to define how to use it in A2DP. And because gstreamer does not
provide this information, the only thing which can be done is definition
of every supported codec in pulseaudio with code which would call
gstreamer function for encoding (or decoding). I think this is too much
work without big benefit for users.

> > --
> > Pali Rohár
> > pali.rohar at gmail.com
> > _______________________________________________
> > pulseaudio-discuss mailing list
> > pulseaudio-discuss at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
> 
> 
> 

-- 
Pali Rohár
pali.rohar at gmail.com