On Friday 08 February 2019 21:44:53 Tanu Kaskinen wrote: > On Tue, 2019-02-05 at 20:35 +0100, Pali Rohár wrote: > > On Tuesday 05 February 2019 21:22:46 Tanu Kaskinen wrote: > > > On Mon, 2019-02-04 at 20:28 +0100, Pali Rohár wrote: > > > > On Monday 28 January 2019 18:50:56 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? > > > > > > > > If profile is "off" then probably the best thing is to choose profile > > > > with higher priority. > > > > > > I again assume you to mean "the highest priority" rather than "[a] > > > higher priority". > > > > (yes, sorry for that) > > > > > The profile with the highest priority may be different than the current > > > codec, or different than the last manually selected codec, so choosing > > > the highest priority profile is not really ideal. > > > > Then we need to maintain persistent cache for every bluetooth device > > what is the preferred codec, plus teach bluetooth policy module to > > switch to this codec (probably after creating bluetooth card? or after > > connecting A2DP profile?). > > In this scenario the card profile is "off" for some reason (maybe the > user chose it, maybe there was some error that made the bluetooth card > switch to off by itself). Now the Gnome sound settings wants to enable > bluetooth output, so how does it choose the profile? I don't see how > modifying module-bluetooth-policy can help here. Right, now I see this is not easy to solve. > > > I really think it would be better to manage the codec choice separately > > > from the profile choice. > > > > But it does not solve your above problem: Which codec should be chosen? > > If the codec with the highest priority is not ideal. > > If the profile selection doesn't dictate the codec, then the Gnome > sound settings doesn't have to care about the codec, it just needs to > enable the A2DP profile. Maybe you meant how can PulseAudio know which > codec should be enabled when the A2DP profile is activated - well, if > A2DP is connected at all, there's already a codec selected, so the > codec doesn't need to be explicitly chosen. Ok. This is truth. > > > > > > 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? > > > > > > > > Why it needs to know it? We use module-bluetooth-policy for switching > > > > from A2DP to HSP when VOIP application starts voice call. > > > > > > > > In V6 now module-bluetooth-policy choose profile with higher priority > > > > which provides both sink and source. In most cases it would be still > > > > HFP/HSP profile, but it may be also A2DP with backchannel support. E.g. > > > > if FastStream codec is supported by headset. > > > > > > Switching from A2DP to HSP is generally not a problem, the thing I had > > > in mind was switching back to A2DP. How does module-bluetooth-policy > > > choose the A2DP profile with the user's preferred codec? > > > > It choose A2DP profile which was used previously before switching to > > HSP. > > > > > Bidirectional A2DP complicates matters also for the A2DP to HSP case, > > > though. Can the user tell PulseAudio to prefer HSP over FastStream? > > > > No. In V6 FastStream codec has higher priority then HSP. So policy > > module choose FastStream (if is supported). Of course user can switch > > from FastStream to HSP manually. > > > > > > > > > > > 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. > > > > > > > > We need to tell developers of all those application that new pulseaudio > > > > API is going to be added into libpulse library and that they need to > > > > extend their existing application to use this API and implement codec > > > > switching. > > > > > > > > We need to do this cooperation, otherwise they would not know that new > > > > API is being prepared and they need to implement this new functionality > > > > into their applications, system settings (or where is audio > > > > configuration implemented). > > > > > > > > Otherwise there would be only pactl support (if we implement it) and it > > > > is really not ideal... > > > > > > Ok, so you're mainly worried about the application developers not > > > knowing about the A2DP codec switching functionality. The functionality > > > will be announced in the release notes, and we can either rely on users > > > to report feature requests to the relevant applications, or we can file > > > those feature requests ourselves. > > > > Yes, but this would take more time and developers probably should > > communicate with us about this API... > > Sure, it will take more time. But I think having separate knobs for > choosing the codec and its parameters it's a better client API in the > long term than stuffing all the parameter permutations in one long > profile list. Not only it takes more time. Question is also who will implement it? Also with argument that codec should not be in profile, we can ask similar question: Why there is special profile for A2DP and special profile for HFP? From user point of view the difference is only between codecs (which is visible in quality of transferred audio). And when codec would not be bound to profile, how users would know which codec is currently in use? > > > By the way, pactl support is not optional. When A2DP codec switching is > > > added to the client API, the patches must extend pactl too. > > > > > > > > > > > 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"? > > > > > > > > If profile is "off" then no codec is active, hmm? > > > > > > I meant the codec that is currently connected in bluez. There's always > > > some codec chosen, unless A2DP is entirely disconnected, right? > > > > Yes, if A2DP profile is not disconnected some codec is chosen. > > > > Cannot we use "profile availability" for this purpose? To indicate which > > one is active? > > Not really. The profile availability is used for indicating which > profiles can be used, so if A2DP is connected, all A2DP profiles with a > supported codec have to be marked as available. In the client API it's > exposed as an int (it would be bool if that wasn't slightly > unportable), so technically we could use more values than just 0 and 1 > to convey some bluetooth specific details about the profile, but that > would be rather ugly. Ok. -- Pali Rohár pali.rohar@xxxxxxxxx _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
