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

[Tanu Kaskinen]

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? Surely you assign some internal priority for the codecs.

If the user has selected a specific codec earlier then that codec
should be selected.

> 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, 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.

How do you decide which A2DP profile to activate in module-bluetooth-
policy?

> > 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.

> 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.

-- 
Tanu

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