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

[Georg Chini]

On 28.01.19 17:50, 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"?
>
One question: There are codecs which support a voice back channel.
Would we not need at least two profiles, one for "normal" A2DP and
one for A2DP with back channel?