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"?
