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
