[pulseaudio-discuss] Bluetooth codec selection

[Tanu Kaskinen]

On Tue, 2020-03-17 at 16:43 +0100, Pali Rohár wrote:
> On Tuesday 17 March 2020 11:23:22 Tanu Kaskinen wrote:
> > On Sun, 2020-01-12 at 12:42 +0100, Pali Rohár wrote:
> > > On Sunday 12 January 2020 09:21:31 Tanu Kaskinen wrote:
> > > > Would you be willing to document the codec negotiation process in the
> > > > wiki?
> > > 
> > > What exactly?
> > 
> > The things that you mentioned below:
> >  * Either side can establish the connection, so it's not obvious what
> > things can trigger a connection. For example, what might cause a
> > headset to initiate the connection?
> >  * BlueZ may decide the codec instead of PulseAudio. What logic does it
> > use?
> >  * There are many places with their own defaults. What are these places
> > and their codec selection logic?
> > 
> > Maybe these things doesn't affect the UI as I first thought, but it
> > would be great to have a reference anyway, so that the system can be
> > understood when debugging codec issues.
> 
> Ok. So after implementation of multicodec support would be in
> pulseaudio I can document how it works and how it can be configured.

Thanks!

> > > > I can give you a wiki account. I believe you have already
> > > > explained this before in emails, but I've forgotten the details. To me
> > > > it would make sense if only the playback side (or the audio gateway for
> > > > bidirectional modes) could decide the codec, but I recall the reality
> > > > is more complicated, and there were multiple places where the chosen
> > > > codec may be remembered.
> > > 
> > > Side which establishing connection choose codec. It does not have to be
> > > playback side. And connection establishment is done by calling DBus
> > > bluez function, independently of pulseaudio (in most cases desktop
> > > bluetooth GUI application do that). So we cannot avoid it.
> > > 
> > > But there are many places which has own defaults. So establishing
> > > connection would work without specifying codec and some remembered /
> > > default value would be used.
> > > 
> > > > The negotiation details affect the constraints
> > > > for UI design.
> > > 
> > > We can do this: When user choose profile, then PA issue command to
> > > activate profile with some default codec. User would see in GUI what was
> > > chosen and could change if is not happy with it. If he does not care
> > > about it he would use default / remembered option and so does not have
> > > to choose anything.
> > 
> > Here's my current overall thinking:
> > 
> > Having the six profiles as you suggested is good.
> > 
> > If I understood correctly, you're proposing to make the sub-profiles a
> > generic concept rather than a bluetooth specific API. I'm a bit
> > hesitant to add an abstraction that doesn't in reality abstract
> > anything, because bluetooth is the only user for now and other users
> > haven't been suggested. On the other hand, I don't foresee concrete
> > problems with this either, so I guess it doesn't really matter.
> 
> Ok. If it simplify things, we can decide that subprofile implementation
> would be in bluetooth pa module and therefore bluetooth specific.
> 
> Now the remaining question is: Which API or solution would be used to
> implement subprofiles (codec selection) by GUI/CLI tools? Pulseaudio
> client <--> server protocol would be needed to extended to support this
> kind of subprofile commands. Or messaging API (still not merged) could
> be used for this.

The messaging API fits better if this is bluetooth specific.

-- 
Tanu

https://www.patreon.com/tanuk
https://liberapay.com/tanuk