[pulseaudio-discuss] Bluetooth aptX codec
Arun Raghavan
arun at arunraghavan.net
Mon Jul 30 11:55:23 UTC 2018
On Mon, 30 Jul 2018, at 5:14 PM, Pali Rohár wrote:
> On Monday 30 July 2018 17:04:55 Arun Raghavan wrote:
> > On Mon, 30 Jul 2018, at 12:42 PM, Pali Rohár wrote:
> > [...]
> > > I looked and there is absolutely nothing about A2DP codec parameter
> > > selections. So really does not help.
> >
> > Okay, I feel like this conversation has been us talking past each other, so let me try to summarise what I'm saying more clearly:
> >
> > 1. The BlueZ modules will, possibly based on modargs, expose a set of supported codecs. Yes, that includes codec parameters, the knowledge of which the endpoint needs to have. If you have ideas for making this modular, I'm open to suggestions.
> >
> > 2. For the specific process of RTP payload/depayload and selection of a codec implementation for encode/decode, I believe we should construct and use a GStreamer bin, so as to not have to offload that choice to the system integrator rather than having to make that choice in PulseAudio. I feel strongly enough about not linking to specific codec implementations that any approach that does that is a NACK from me. I realise we already have this for SBC, but I do not want to add any more.
>
> Look at my last (v2) patch series for aptX. Here I created some
> modularisation of codecs and addition of another codecs would be easier.
Will do. Note that I'm not just talk about modularity w.r.t. codecs, but also codec implementations.
> I have not used Gstreamer as it does not help me -- it does not provide
> module for A2DP codec negotiation (it is not static list of parameters
> as you imagine, but negotiation function) nor it does not support aptX
> codec.
That's still not problematic from a GStreamer perspective. It is possible to set up parameters via caps if needed after the negotiation stage. And wrapping your library in a GStreamer plugin would be a trivial effort.
-- Arun
More information about the pulseaudio-discuss
mailing list