[pulseaudio-discuss] Bluetooth aptX codec
Arun Raghavan
arun at arunraghavan.net
Mon Jul 30 02:45:22 UTC 2018
On Sat, 28 Jul 2018, at 9:01 PM, Pali Rohár wrote:
> On Monday 23 July 2018 18:42:52 Arun Raghavan wrote:
> > On Sun, 8 Jul 2018, at 12:14 AM, Pali Rohár wrote:
> > > On Sunday 08 July 2018 01:44:39 Alexander E. Patrakov wrote:
> > > > сб, 7 июл. 2018 г. в 19:08, Pali Rohár <pali.rohar at gmail.com>:
> > > > >
> > > > > On Saturday 07 July 2018 09:39:53 Arun Raghavan wrote:
> > > > > > Pre-installed doesn't mean much tbh. It is easy enough for packages to depend on it.
> > > > >
> > > > > Can pulseaudio build process enforce it?
> >
> > Does not need to, that can be taken care of at packaging time, and potentially at module load.
>
> Ok, I would ask differently: Can pulseaudio at packaging time enforce it?
That depends on the packaging system, but broadly the answer is yes.
> > > > 2. GStreamer can, in theory, wrap the needed libraries, and does
> > > > support third-party plugins, but does not properly encapsulate the
> > > > "give me packets ready to send via bluez" part.
> > >
> > > And until this is supported by external library (ffmpeg, gstreamer,
> > > whatever), pulseaudio needs to implement it itself.
> > >
> > > And encapsulating encoded data for bluez is not enough. It is needed
> > > also to negotiate codec selection with bluez and codec parameters (which
> > > are codec specific).
> >
> > GStreamer has RTP payloading for sbc, mp3 and aac, so that can easily be used (and again, less codec-specific stuff that needs to be in PA).
>
> But it does not solve above problem when it is needed to do A2DP codec
> selection and negotiation.
I don't get what you mean here.
> > > In previous email I wrote about idea to move that codec stuff into bluez
> > > itself as bluez code already handles it for android.
> > >
> > > > >
> > > > > > > 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
> > > > > function.
> > > > >
> > > > > 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).
> >
> > At least for SBC and presumably AAC, this is all possible with GStreamer
>
> No, it is not possible -- or at least I have not found any way how. I
> spend more time with it and Gstreamer does not support it. If you still
> think that it is possible, post a gstreamer code or link how to do that.
Look at the rtpsbcpay/rtpsbcdepay elements, for example.
-- Arun
More information about the pulseaudio-discuss
mailing list