[pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs

Mon Feb 4 18:06:09 UTC 2019

Ping? There were some questions in the message below that I'd like to
get some kind of answers to.

-- Tanu

On Mon, 2019-01-28 at 18:50 +0200, Tanu Kaskinen wrote:
> On Fri, 2019-01-25 at 16:41 +0100, Pali Rohár wrote:
> > On Friday 25 January 2019 17:11:00 Tanu Kaskinen wrote:
> > > On Fri, 2019-01-25 at 11:02 +0100, Pali Rohár wrote:
> > > > On Friday 25 January 2019 11:49:32 Tanu Kaskinen wrote:
> > > > > On Sat, 2019-01-19 at 18:11 +0100, Pali Rohár wrote:
> > > > > > This is 5th version of my patch series for modular A2DP codec API and
> > > > > > aptX support. The only change for v5 is support for switching codecs.
> > > > > > 
> > > > > > This patch series provides new modular API for Bluetooth A2DP codecs,
> > > > > > clean up module-bluez5-device and bluez5-util to be codec independent
> > > > > > and convert SBC codec into this new API for A2DP codecs. Also it adds
> > > > > > support for aptX, aptX HD and FastStream A2DP codecs.
> > > > > > 
> > > > > > New codec API is designed in way, that for adding new codec is not
> > > > > > needed to touch bluez5-util nor module-bluez5-device files. Whole
> > > > > > codec registration is done in a2dp-codec-util.c file, without need
> > > > > > to update any header file.
> > > > > > 
> > > > > > Some A2DP codecs are bidirectional and support backchannel for
> > > > > > microphone voice. This new A2DP codec API fully supports this feature
> > > > > > and module-bluez5-device was extended to support microphone voice source
> > > > > > for codecs which declares such support. FastStream is such codec.
> > > > > > 
> > > > > > For every A2DP codec is created card profile. When using bluez patches
> > > > > > from https://marc.info/?l=linux-bluetooth&m=154696260401673&w=2 then
> > > > > > only those profiles codec profiles are created which are supported
> > > > > > by remote headset/endpoint.
> > > > > 
> > > > > As discussed before, I don't think the codec configuration should be
> > > > > exposed via card profiles.
> > > > > There is need for being able to say "switch
> > > > > to A2DP" without specifying the codec.
> > > > 
> > > > So which codec should be chosen when you do not specify it? That is the
> > > > most important question if codec is going to be hidden.
> > > 
> > > Well, which codec do you choose by default when connecting a new
> > > device?
> > 
> > Not choosing any. When creating a connection, codec selection is up to
> > the remote device and bluez, on what they decide.
> > 
> > > Surely you assign some internal priority for the codecs.
> > > 
> > > If the user has selected a specific codec earlier then that codec
> > > should be selected.
> > 
> > That is again not under pulseaudio control. When initializing connection
> > it is up to the bluez and remote device.
> > 
> > Bluez has now API for switching A2DP codec, by doing disconnect and
> > initializing a new connection with chosen endpoint (codec). And this is
> > what happen when profile is going to be switched in pulseaudio.
> > 
> > Yes, we can probably implement per-device priority in way that after
> > bluez initialize connection, we use API for codec switching to one which
> > we want. But this is, I think rather complicated. And if it is really
> > needed we can try to implement it later once everything other is
> > working.
> 
> Thanks for the explanation.
> 
> > > > And if codec is exported as card profile, is not operation "switch to
> > > > A2DP" same as "switch to A2DP profile with higher priority"?
> > > 
> > > Do you mean "the highest priority" rather than "higher priority"? Is
> > > your idea that when e.g. Gnome audio settings wants to enable bluetooth
> > > output,
> > 
> > What do you mean by "wants to enable bluetooth output"?
> 
> Let's say that the bluetooth card profile is "off". The user opens the
> Gnome audio settings and selects the bluetooth headset as the new
> output device (there is one device entry in the Gnome UI despite
> multiple profiles). How does Gnome audio settings decide which profile
> to select?
> 
> > Because you cannot initialize A2DP connection from pulseaudio (or at
> > least pulseaudio does not support it). Initializing connection is done
> > from bluez client (on KDE it is bluedevil). And pulseaudio allows to
> > choose A2DP profile only if connection is already established by bluez.
> > 
> > > it should look at all output profiles on the card and pick the
> > > one with the highest priority? I suppose that would work, and quite
> > > possibly that's what it already does. That requires the profile
> > > priorities to be dynamic, however, so that when the user selects a
> > > profile, it becomes the highest priority codec.
> > 
> > Currently codecs have priority number which is exported to pulseaudio
> > profiles. Also priority number depends on other in which pulseaudio dbus
> > endpoints for bluez are registered. bluez internally used them for
> > deciding which codec to choose -- but it is global for all remote
> > device, not decide specific.
> > 
> > > How do you decide which A2DP profile to activate in module-bluetooth-
> > > policy?
> > 
> > At which time? module-bluetooth-policy should just switch to A2DP
> > profile which belong to endpoint which bluez activated.
> 
> How does module-bluetooth-policy know which endpoint bluez has
> activated?
> 
> > > > > It's unclear how priority of the codecs (and their parameter
> > > > > permutations) should be configured, but it seems quite clear that a
> > > > > "set codec" operation on a specific card would be useful. If the "set
> > > > > codec" operation is separate from "set profile" operation, then you no
> > > > > doubt will ask how to implement the client API for this new operation,
> > > > > and I don't have a very good answer.
> > > > > 
> > > > > Georg Chini has been working on a new messaging API, which would be a
> > > > > good fit for this, but that's stalled (I don't remember if it's waiting
> > > > > for review or a new version of the patches). If you don't want to be
> > > > > blocked by that, the alternative is to add new "get bluetooth card
> > > > > info" and "set bluetooth card a2dp codec" commands to the core protocol
> > > > > (the card info command would be for enumerating the available codecs),
> > > > > or to add the commands via a new "protocol extension" similar to what
> > > > > module-stream-restore, module-device-restore and module-device-manager
> > > > > do. I would be fine with either approach.
> > > > > 
> > > > > Adding new commands to the core protocol would be somewhat simpler, but
> > > > > I'm not sure other maintainers are ok with adding bluetooth specific
> > > > > functionality to the core protocol.
> > > > 
> > > > All this seems like bluetooth specific. Extending core protocol API for
> > > > bluetooth specific API means that all applications needs to be extended
> > > > to support it.
> > > > 
> > > > So for choosing A2DP codec, it would be needed to extend KDE sound
> > > > system settings application, Gnome configuration, and also other...
> > > > 
> > > > I think this is too complicated and needs cooperation with other
> > > > projects and team.
> > > 
> > > Well, I disagree about it being too complicated, and there's no need
> > > for any particular cooperation effort. UIs that want to change the
> > > codec just need to be updated to take advantage of the new feature. No
> > > functionality is degraded even if they don't adapt.
> > 
> > Yes, no functionality is degraded, but no functionality is also added.
> > And extending UI, logic behind it and so... needs cooperation with other
> > projects and teams. Without it there is zero benefit for pulseaudio for
> > ability to switch codecs -- as nobody would use it.
> 
> Why would nobody use it? At the very least pactl is available. I still
> don't know what cooperation you're talking about. If you think we
> should ask the UI developers what they want before we add a new API for
> choosing the a2dp codec, then that discussion should be had anyway
> before doing anything else, because your current patches are forcing
> them to use the card profile API for selecting the a2dp codec.
> 
> > > > With profiles it is simple as it is already supported in desktop
> > > > environments.
> > > 
> > > That's certainly a benefit. The problem is just that forcing the user
> > > to make a choice between codecs isn't very nice if the user doesn't
> > > know the practical difference between the provided options.
> > 
> > User is not forced. Bluez and remote device choose codec for him. And if
> > user is not happy with selection then can change it to something
> > different which "plays better".
> > 
> > We already have module bluetooth policy which switch between HFP and
> > A2DP profiles based on active VOIP application. So user already has
> > microphone support when calling. And after hanging call policy module
> > should switch back to previous A2DP profile (codec) without user
> > interaction.
> > 
> > So I do not think it is such catastrophic that user need to choose
> > something. User has already pre-selected some A2DP variant. And based on
> > fact that lot of headsets remember last used codec per device, it is not
> > such a big problem.
> 
> Yeah, it seems that the need to choose the card profile isn't very
> common. But there can be situations where the user wants to just
> activate the A2DP profile. How do you communicate to the user which
> codec is currently active if the card profile is "off"?