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"? _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
