Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Tue, 2019-02-12 at 10:14 +0100, Pali Rohár wrote: > 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: > > > > > > > > > > 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
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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 t
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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 choosi
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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". 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. I really think it would be better to manage the codec choice separately from the profile choice. > > > 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
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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. > > 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 > > decid
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Thursday 31 January 2019 22:04:32 Pali Rohár wrote: > On Thursday 31 January 2019 20:09:06 Tanu Kaskinen wrote: > > On Mon, 2019-01-28 at 18:01 +0100, Georg Chini wrote: > > > 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? > > > > Yes, you're right, even if we don't have per-codec profiles, we'll need > > a separate bidirectional A2DP profile when that's implemented (IIRC > > it's not yet implemented by these patches). > > It is implemented in this patch series (FastStream codec) and it is > working. > > I will send a new version with other fixes, like that profile switching. Done! V6 was sent. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Saturday 26 January 2019 00:09:17 Pali Rohár wrote: > On Friday 25 January 2019 11:04:22 Tanu Kaskinen wrote: > > On Wed, 2019-01-23 at 18:52 +0100, Pali Rohár wrote: > > > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > > > Hi Pali, > > > > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > > > > I think that this patch series is now ready for review and testing. > > > > > All > > > > > needed parts are finished. > > > > > > > > > > The only problem is with asynchronous profile switching as function > > > > > pa_card_set_profile() does not support it. All details are in patch > > > > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > > > > > > > So can you look at this patch series and review it? > > > > > > > > I tested this today, it seems to work fine with sbc but with > > > > faststream there seems to be some problem somewhere as it does seems > > > > to consume too much cpu time. Regarding set_profile that is something > > > > I think we will need to address otherwise the UI is pretty much > > > > useless to switch as it doesn't seems to react well when -EAGAIN is > > > > returned, we could perhaps block on SetConfiguration since we do block > > > > on Acquire anyway, or you have already tried that? > > > > > > Yes, I tried it. Pulseaudio blocks communication and therefore it also > > > does not receive following DBus requests from bluez and so > > > SetConfiguration timeout. > > > > > > In fact -EAGAIN is just dropped in pulseaudio bluetooth module and > > > replaced by -1. I just wanted to "highlight" that part of code, so I > > > used -EAGAIN, but it has same meaning as any other non-zero value. > > > > > > I was thinking about it and we could block this on another layer. > > > pa_card_set_profile() is called when application request to change > > > profile via PA socket. So extend pa_card_set_profile() API to pass > > > callback function which would be called after profile is changed > > > asynchronously. And just block user request until callback is called. > > > > > > Maybe some other people who understand pulseaudio better can help? How > > > to implement asynchronous profile switching? > > > > To me it seems that either pa_card_set_profile() should be made > > asynchronous, which would be nice, because it would allow errors to be > > reported properly, or the bluetooth code should just initiate the > > profile change operation and pretend that the switching always > > succeeds. In the latter option, in case of failure the bluetooth code > > would switch to the off profile. > > > > I'm fine with either option. > > Seems that immediate switch to profile is easier as implementing whole > asynchronous operations. Implemented in v6 and it is working fine! If asynchronous operations are needed, it should be implemented in future and bluetooth code can be then switched to that API. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Thursday 31 January 2019 20:09:06 Tanu Kaskinen wrote: > On Mon, 2019-01-28 at 18:01 +0100, Georg Chini wrote: > > 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: > > > > > > 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? > > Yes, you're right, even if we don't have per-codec profiles, we'll need > a separate bidirectional A2DP profile when that's implemented (IIRC > it's not yet implemented by these patches). It is implemented in this patch series (FastStream codec) and it is working. I will send a new version with other fixes, like that profile switching. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Mon, 2019-01-28 at 18:01 +0100, Georg Chini wrote: > 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: > > > > > 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? Yes, you're right, even if we don't have per-codec profiles, we'll need a separate bidirectional A2DP profile when that's implemented (IIRC it's not yet implemented by these patches). -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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 t
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Saturday 26 January 2019 12:13:38 Pasi Kärkkäinen wrote: > On Sat, Jan 26, 2019 at 07:39:54AM +0530, Arun Raghavan wrote: > > On Fri, 25 Jan 2019, at 3:19 PM, 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. > > > > I strongly agree with this. Separate profiles for each codec is simply not > > the way to go -- it's horrible for usability. > > > > > 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. > > > > I don't think adding this to the core is necessarily the best option, but I > > think this is a separate problem. > > > > The current patchset should, imo, just take a priority-ordered list of > > codecs as a modarg and use that (we can choose some default if it is not > > specified, also ideally based on what codecs are supported on the system -- > > as I've suggested before, I don't want us to depend on the codec > > implementation, but I can help deal with that as a separate step). > > > > So the modarg approach gives us a static configuration option for people > > who care about this setting immediately, with a sensible default for most > > of our users who will not. How we can make this runtime configurable can be > > figured out separately (for example, with Georg's on-going work). > > > > Some thoughts about choosing the "best" codec.. which is quite subjective, > depending on what the user wants to achieve, for example: > > 1) To get the best audio quality: > - Example priority of codecs: LDAC (most preferred), HWA LHDC, AptX HD, AptX, > AAC, SBC There is no much difference in quality between aptX and SBC in High Quality mode. And SBC with bigger bitpool could provide higher quality as aptX. Now I'm playing with registering more variants of SBC into my codec API, to have SBC fixed at Low, Middle and High Quality. Plus with "above Hight Quality". E.g. with bitpool 76 SBC (joint stereo) could provide 454.8 kbps bitrate. Or with bitpool 38 (for devices which are limited to bitpool 53) in dual channel mode it is similar, 452 kbps bitrate. I can send patches, after I have it working and cleaned up. > > 2) To get the smallest/least latency (to lip-sync videos, for gaming, etc): > - Example priority of codecs: AptX Low Latency (AptX-LL, most preferred)
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
Hi all, On Sat, Jan 26, 2019 at 3:57 PM Pasi Kärkkäinen wrote: > > On Sat, Jan 26, 2019 at 07:39:54AM +0530, Arun Raghavan wrote: > > On Fri, 25 Jan 2019, at 3:19 PM, 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. > > > > I strongly agree with this. Separate profiles for each codec is simply not > > the way to go -- it's horrible for usability. > > > > > 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. > > > > I don't think adding this to the core is necessarily the best option, but I > > think this is a separate problem. > > > > The current patchset should, imo, just take a priority-ordered list of > > codecs as a modarg and use that (we can choose some default if it is not > > specified, also ideally based on what codecs are supported on the system -- > > as I've suggested before, I don't want us to depend on the codec > > implementation, but I can help deal with that as a separate step). > > > > So the modarg approach gives us a static configuration option for people > > who care about this setting immediately, with a sensible default for most > > of our users who will not. How we can make this runtime configurable can be > > figured out separately (for example, with Georg's on-going work). > > > > Some thoughts about choosing the "best" codec.. which is quite subjective, > depending on what the user wants to achieve, for example: > > 1) To get the best audio quality: > - Example priority of codecs: LDAC (most preferred), HWA LHDC, AptX HD, AptX, > AAC, SBC > > > 2) To get the smallest/least latency (to lip-sync videos, for gaming, etc): > - Example priority of codecs: AptX Low Latency (AptX-LL, most preferred), > FastStream, SBC > > > 3) To get the best battery life on your headset (I've read about some > heaphones which have the best battery life with AAC, and for example AptX or > LDAC uses more battery on that device) > - Example priority of codecs: AAC (most preferred), SBC We could in theory change the codecs on demand but that could introduce glitches since during the switching the audio cannot be rendered, because of that Im in favour o user selecting the codec and then that being remembered by PA when reconnecting. If it is implemented this way I don't think
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Sat, Jan 26, 2019 at 07:39:54AM +0530, Arun Raghavan wrote: > On Fri, 25 Jan 2019, at 3:19 PM, 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. > > I strongly agree with this. Separate profiles for each codec is simply not > the way to go -- it's horrible for usability. > > > 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. > > I don't think adding this to the core is necessarily the best option, but I > think this is a separate problem. > > The current patchset should, imo, just take a priority-ordered list of codecs > as a modarg and use that (we can choose some default if it is not specified, > also ideally based on what codecs are supported on the system -- as I've > suggested before, I don't want us to depend on the codec implementation, but > I can help deal with that as a separate step). > > So the modarg approach gives us a static configuration option for people who > care about this setting immediately, with a sensible default for most of our > users who will not. How we can make this runtime configurable can be figured > out separately (for example, with Georg's on-going work). > Some thoughts about choosing the "best" codec.. which is quite subjective, depending on what the user wants to achieve, for example: 1) To get the best audio quality: - Example priority of codecs: LDAC (most preferred), HWA LHDC, AptX HD, AptX, AAC, SBC 2) To get the smallest/least latency (to lip-sync videos, for gaming, etc): - Example priority of codecs: AptX Low Latency (AptX-LL, most preferred), FastStream, SBC 3) To get the best battery life on your headset (I've read about some heaphones which have the best battery life with AAC, and for example AptX or LDAC uses more battery on that device) - Example priority of codecs: AAC (most preferred), SBC So yeah, depending on the use case / scenario, the priorify of codecs for negotiation is different.. and the users most probably also want to be able to force usage of specific codec. > -- Arun -- Pasi ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Saturday 26 January 2019 03:59:54 Arun Raghavan wrote: > On Sat, 26 Jan 2019, at 2:15 PM, Pali Rohár wrote: > > On Saturday 26 January 2019 07:39:54 Arun Raghavan wrote: > > > On Fri, 25 Jan 2019, at 3:19 PM, 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. > > > > > > I strongly agree with this. Separate profiles for each codec is simply > > > not the way to go -- it's horrible for usability. > > > > Why it is horrible? > > > > I think horrible is when you need to introduce a new API into pulseaudio > > core for adding ability for switching to codec which supports > > microphone. > > > > Same for having hardcoded priority list of codecs somewhere in config > > file or in module argument. > > > > It would mean that switching to codec with microphone support cannot be > > done in existing GUI tools and it is needed to edit config file or > > re-load bluetooth module. This is horrible. > > Perhaps my phrasing was a bit harsh, apologies if you found it so. > > Having users to through a drop-down list for codec selection is unfriendly > from a UX perspective was what I was getting at. For me this is a > non-starter. For most people, this is configuration they don't and shouldn't > care about. We should have sensible defaults and they should just work. Look at my reply which I sent to Tanu. Pulseaudio is not choosing A2DP codec. It is up to the bluez and remote device. So there is always some default from "other-side". So user does not have to do codec selection if is not interested in it. It is there as ability to view which codec is in use and ability to change codec if user is not satisfied with current one (for any reason). I do not understand your arguments. If there should be support for codec selection then some drop down list in any form is needed. And if there cannot be drop down selection list, then profile switching is not need at all to implement as nobody can use it. Once you have N codecs then for switching you need UI where these N options are available. It is not possible to reduce it to less then N options whatever UX friendly/unfriendly it is. > For people who do care, you're right, this is a gap in what PulseAudio > currently supports. While we discuss a solution, a modarg allows us to take > the existing work forward, especially since that configuration is only one > independent part of whole. > > I do not follow what you mean about codec with a microphone. If you mean A2DP > source+sink at the same time with one of these codecs, No, I mean A2DP sink with voice backchannel support (for microphone data) which is in this patch series. Some A2DP codecs support it, e.g. FastStream. Other (not included in this patch series) is aptX Low Latency and I guess there are others too. > I think this is not common enough to make everything For Creative headsets it is very common, and aptX Low Latency codec is not uncommon too. > else user unfriendly and we can still try to find a way to enable it that > doesn't require codec selection via profiles. > > -- Arun -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Sat, 26 Jan 2019, at 2:15 PM, Pali Rohár wrote: > On Saturday 26 January 2019 07:39:54 Arun Raghavan wrote: > > On Fri, 25 Jan 2019, at 3:19 PM, 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. > > > > I strongly agree with this. Separate profiles for each codec is simply not > > the way to go -- it's horrible for usability. > > Why it is horrible? > > I think horrible is when you need to introduce a new API into pulseaudio > core for adding ability for switching to codec which supports > microphone. > > Same for having hardcoded priority list of codecs somewhere in config > file or in module argument. > > It would mean that switching to codec with microphone support cannot be > done in existing GUI tools and it is needed to edit config file or > re-load bluetooth module. This is horrible. Perhaps my phrasing was a bit harsh, apologies if you found it so. Having users to through a drop-down list for codec selection is unfriendly from a UX perspective was what I was getting at. For me this is a non-starter. For most people, this is configuration they don't and shouldn't care about. We should have sensible defaults and they should just work. For people who do care, you're right, this is a gap in what PulseAudio currently supports. While we discuss a solution, a modarg allows us to take the existing work forward, especially since that configuration is only one independent part of whole. I do not follow what you mean about codec with a microphone. If you mean A2DP source+sink at the same time with one of these codecs, I think this is not common enough to make everything else user unfriendly and we can still try to find a way to enable it that doesn't require codec selection via profiles. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Saturday 26 January 2019 07:39:54 Arun Raghavan wrote: > On Fri, 25 Jan 2019, at 3:19 PM, 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. > > I strongly agree with this. Separate profiles for each codec is simply not > the way to go -- it's horrible for usability. Why it is horrible? I think horrible is when you need to introduce a new API into pulseaudio core for adding ability for switching to codec which supports microphone. Same for having hardcoded priority list of codecs somewhere in config file or in module argument. It would mean that switching to codec with microphone support cannot be done in existing GUI tools and it is needed to edit config file or re-load bluetooth module. This is horrible. > > 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. > > I don't think adding this to the core is necessarily the best option, but I > think this is a separate problem. > > The current patchset should, imo, just take a priority-ordered list of codecs > as a modarg and use that (we can choose some default if it is not specified, > also ideally based on what codecs are supported on the system -- as I've > suggested before, I don't want us to depend on the codec implementation, but > I can help deal with that as a separate step). > > So the modarg approach gives us a static configuration option for people who > care about this setting immediately, with a sensible default for most of our > users who will not. How we can make this runtime configurable can be figured > out separately (for example, with Georg's on-going work). > > -- Arun -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Fri, 25 Jan 2019, at 3:19 PM, 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. I strongly agree with this. Separate profiles for each codec is simply not the way to go -- it's horrible for usability. > 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. I don't think adding this to the core is necessarily the best option, but I think this is a separate problem. The current patchset should, imo, just take a priority-ordered list of codecs as a modarg and use that (we can choose some default if it is not specified, also ideally based on what codecs are supported on the system -- as I've suggested before, I don't want us to depend on the codec implementation, but I can help deal with that as a separate step). So the modarg approach gives us a static configuration option for people who care about this setting immediately, with a sensible default for most of our users who will not. How we can make this runtime configurable can be figured out separately (for example, with Georg's on-going work). -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Friday 25 January 2019 11:04:22 Tanu Kaskinen wrote: > On Wed, 2019-01-23 at 18:52 +0100, Pali Rohár wrote: > > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > > > I think that this patch series is now ready for review and testing. All > > > > needed parts are finished. > > > > > > > > The only problem is with asynchronous profile switching as function > > > > pa_card_set_profile() does not support it. All details are in patch > > > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > > > > > So can you look at this patch series and review it? > > > > > > I tested this today, it seems to work fine with sbc but with > > > faststream there seems to be some problem somewhere as it does seems > > > to consume too much cpu time. Regarding set_profile that is something > > > I think we will need to address otherwise the UI is pretty much > > > useless to switch as it doesn't seems to react well when -EAGAIN is > > > returned, we could perhaps block on SetConfiguration since we do block > > > on Acquire anyway, or you have already tried that? > > > > Yes, I tried it. Pulseaudio blocks communication and therefore it also > > does not receive following DBus requests from bluez and so > > SetConfiguration timeout. > > > > In fact -EAGAIN is just dropped in pulseaudio bluetooth module and > > replaced by -1. I just wanted to "highlight" that part of code, so I > > used -EAGAIN, but it has same meaning as any other non-zero value. > > > > I was thinking about it and we could block this on another layer. > > pa_card_set_profile() is called when application request to change > > profile via PA socket. So extend pa_card_set_profile() API to pass > > callback function which would be called after profile is changed > > asynchronously. And just block user request until callback is called. > > > > Maybe some other people who understand pulseaudio better can help? How > > to implement asynchronous profile switching? > > To me it seems that either pa_card_set_profile() should be made > asynchronous, which would be nice, because it would allow errors to be > reported properly, or the bluetooth code should just initiate the > profile change operation and pretend that the switching always > succeeds. In the latter option, in case of failure the bluetooth code > would switch to the off profile. > > I'm fine with either option. Seems that immediate switch to profile is easier as implementing whole asynchronous operations. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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. > > 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"? 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. > > > 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
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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 ___ pulseaudio-discuss mailin
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On 25.01.19 10:49, 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. 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). It has been waiting for a new version. Meanwhile I got around to work on this again and will probably send a new patch set in a couple of days. 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. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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. And if codec is exported as card profile, is not operation "switch to A2DP" same as "switch to A2DP profile with higher priority"? > 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. With profiles it is simple as it is already supported in desktop environments. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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. 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. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Wed, 2019-01-23 at 18:52 +0100, Pali Rohár wrote: > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > Hi Pali, > > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > > I think that this patch series is now ready for review and testing. All > > > needed parts are finished. > > > > > > The only problem is with asynchronous profile switching as function > > > pa_card_set_profile() does not support it. All details are in patch > > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > > > So can you look at this patch series and review it? > > > > I tested this today, it seems to work fine with sbc but with > > faststream there seems to be some problem somewhere as it does seems > > to consume too much cpu time. Regarding set_profile that is something > > I think we will need to address otherwise the UI is pretty much > > useless to switch as it doesn't seems to react well when -EAGAIN is > > returned, we could perhaps block on SetConfiguration since we do block > > on Acquire anyway, or you have already tried that? > > Yes, I tried it. Pulseaudio blocks communication and therefore it also > does not receive following DBus requests from bluez and so > SetConfiguration timeout. > > In fact -EAGAIN is just dropped in pulseaudio bluetooth module and > replaced by -1. I just wanted to "highlight" that part of code, so I > used -EAGAIN, but it has same meaning as any other non-zero value. > > I was thinking about it and we could block this on another layer. > pa_card_set_profile() is called when application request to change > profile via PA socket. So extend pa_card_set_profile() API to pass > callback function which would be called after profile is changed > asynchronously. And just block user request until callback is called. > > Maybe some other people who understand pulseaudio better can help? How > to implement asynchronous profile switching? To me it seems that either pa_card_set_profile() should be made asynchronous, which would be nice, because it would allow errors to be reported properly, or the bluetooth code should just initiate the profile change operation and pretend that the switching always succeeds. In the latter option, in case of failure the bluetooth code would switch to the off profile. I'm fine with either option. In case you wanted some more detailed thoughts about implementation, here's what I'd do if I chose the "make pa_card_set_profile() asynchronous" option: pa_card_set_profile() should be renamed to pa_card_set_profile_begin(). It would take a user callback to be called when the operation finishes. pa_card_set_profile_begin() should return an operation object similar to pa_operation in the client API (but I believe pa_operation is not suitable to be used in the core, because it's tied to pa_context, and I also dislike its use of reference counting). The operation object would store the callback and any other necessary information related to the profile switch. The operation object would be created by pa_card_set_profile_begin() and owned by pa_card. The card backend can also save some backend specific data in the operation object. Once the profile switch completes, the card backend should set the result information (success/failure, error codes, etc.) in the operation object and call pa_card_set_profile_finish() with the operation object as an argument. pa_card_set_profile_finish() would then call the user callback and free the operation object. The operation needs to be cancellable too. If pa_card_set_profile_begin() is called while there's an older operation still in progress, the old operation needs to be cancelled. The card backend needs to set a callback in the operation object to get notified about cancellation. The pa_card_set_profile_begin() user can probably handle a cancellation in the same way it handles any kind of failure (so it gets notified via the operation user callback). When the card is destroyed, any ongoing asynchronus operation needs to be cancelled. It would probably be a good idea to define a generic asynchronous operation object at some point (the name could be pa_async_operation), but as long as pa_card_set_profile() remains the only user for such functionality, we can begin by making the operation object specific to the profile switch operation, which would keep things a bit less complex. -- Tanu https://www.patreon.com/tanuk https://liberapay.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Thursday 24 January 2019 16:12:23 Luiz Augusto von Dentz wrote: > Hi Pali, > On Thu, Jan 24, 2019 at 11:28 AM Pali Rohár wrote: > > > Perhaps that was used to compensate the transmission latency, but that > > > would be different for SCO and A2DP, but I tried with just 5 ms and it > > > seems to work pretty well: > > > > Is is possible to retrieve (from kernel? bluez?) transmission latency? > > Well that is not a fixed delay, besides PA seems to be already taking > some extra latency time into account as it does 2 times some latency I > assume that is the hardware which in this case would be the Bluetooth > radi. But does kernel/bluez provides something? > > > I: [lt-pulseaudio] protocol-native.c: Final latency 100.00 ms = 25.01 > > > ms + 2*24.99 ms + 25.01 ms > > > > > > As oppose to something like 140 ms which the original code produces. > > > > I think that adding a new function for codec API which calculates codec > > latency is the correct way how to deal with it. > > Yep, indeed we need something to take into account the different > algorithm delays. > > Btw, Ive send a review about the a2dp codec API but apparently it is > stuck due to its size, so someone needs to approve it. It is In next round try to remove chunks of patches which you have not commented. This should decrease size of email. > suggesting some changes to the naming, etc, but I think I found a real > bug in which the endpoints hash function is used incorrectly since you > just pass the endpoint path not the struct pa_a2dp_codec_id. I do not think this is a bug, but rather slightly complicated structure and probably harder to understand. I though it is obvious, so I have not put there lot of comments. But seems not and some deep look is needed to understand two level hash tables. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
Hi Pali, On Thu, Jan 24, 2019 at 11:28 AM Pali Rohár wrote: > > Perhaps that was used to compensate the transmission latency, but that > > would be different for SCO and A2DP, but I tried with just 5 ms and it > > seems to work pretty well: > > Is is possible to retrieve (from kernel? bluez?) transmission latency? Well that is not a fixed delay, besides PA seems to be already taking some extra latency time into account as it does 2 times some latency I assume that is the hardware which in this case would be the Bluetooth radi. > > I: [lt-pulseaudio] protocol-native.c: Final latency 100.00 ms = 25.01 > > ms + 2*24.99 ms + 25.01 ms > > > > As oppose to something like 140 ms which the original code produces. > > I think that adding a new function for codec API which calculates codec > latency is the correct way how to deal with it. Yep, indeed we need something to take into account the different algorithm delays. Btw, Ive send a review about the a2dp codec API but apparently it is stuck due to its size, so someone needs to approve it. It is suggesting some changes to the naming, etc, but I think I found a real bug in which the endpoints hash function is used incorrectly since you just pass the endpoint path not the struct pa_a2dp_codec_id. -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Thursday 24 January 2019 11:13:35 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Jan 23, 2019 at 7:52 PM Pali Rohár wrote: > > > > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > > > > > > > I think that this patch series is now ready for review and testing. All > > > > needed parts are finished. > > > > > > > > The only problem is with asynchronous profile switching as function > > > > pa_card_set_profile() does not support it. All details are in patch > > > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > > > > > So can you look at this patch series and review it? > > > > > > I tested this today, it seems to work fine with sbc but with > > > faststream there seems to be some problem somewhere as it does seems > > > to consume too much cpu time. Regarding set_profile that is something > > > I think we will need to address otherwise the UI is pretty much > > > useless to switch as it doesn't seems to react well when -EAGAIN is > > > returned, we could perhaps block on SetConfiguration since we do block > > > on Acquire anyway, or you have already tried that? > > > > Yes, I tried it. Pulseaudio blocks communication and therefore it also > > does not receive following DBus requests from bluez and so > > SetConfiguration timeout. > > Right there are D-Bus messages when switching the endpoint, though > what we could perhaps do is create the sink suspended like how it is > done in case of oFono, or at least that is how I remembered it. > > > In fact -EAGAIN is just dropped in pulseaudio bluetooth module and > > replaced by -1. I just wanted to "highlight" that part of code, so I > > used -EAGAIN, but it has same meaning as any other non-zero value. > > > > I was thinking about it and we could block this on another layer. > > pa_card_set_profile() is called when application request to change > > profile via PA socket. So extend pa_card_set_profile() API to pass > > callback function which would be called after profile is changed > > asynchronously. And just block user request until callback is called. > > > > Maybe some other people who understand pulseaudio better can help? How > > to implement asynchronous profile switching? > > > > > Another thing I noticed, we should start taking into accound the > > > algorithm delay of each codec instead of adding a fixed delay of 25 > > > ms, in fact 25 ms seems wrong even for SBC since it has about 5 ms of > > > delay not 25 ms. > > > > Yes, this is something I wanted to start addressing. aptX has fixed > > delay of 90 samples. Do you have some pointer there can be that delay > > configured? Or where is that fixed delay hardcoded? > > It is hardcoded in FIXED_LATENCY_PLAYBACK_A2DP which is added like this: > > pa_sink_set_fixed_latency_within_thread(u->sink, > > (pa_bluetooth_profile_is_a2dp(u->profile) ? > > FIXED_LATENCY_PLAYBACK_A2DP : FIXED_LATENCY_PLAYBACK_SCO) + > > pa_bytes_to_usec(u->write_block_size, &u->encoder_sample_spec)); Thanks! > Perhaps that was used to compensate the transmission latency, but that > would be different for SCO and A2DP, but I tried with just 5 ms and it > seems to work pretty well: Is is possible to retrieve (from kernel? bluez?) transmission latency? > I: [lt-pulseaudio] protocol-native.c: Final latency 100.00 ms = 25.01 > ms + 2*24.99 ms + 25.01 ms > > As oppose to something like 140 ms which the original code produces. I think that adding a new function for codec API which calculates codec latency is the correct way how to deal with it. -- Pali Rohár pali.ro...@gmail.com ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
Hi Pali, On Wed, Jan 23, 2019 at 7:52 PM Pali Rohár wrote: > > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > Hi Pali, > > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > > > > > I think that this patch series is now ready for review and testing. All > > > needed parts are finished. > > > > > > The only problem is with asynchronous profile switching as function > > > pa_card_set_profile() does not support it. All details are in patch > > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > > > So can you look at this patch series and review it? > > > > I tested this today, it seems to work fine with sbc but with > > faststream there seems to be some problem somewhere as it does seems > > to consume too much cpu time. Regarding set_profile that is something > > I think we will need to address otherwise the UI is pretty much > > useless to switch as it doesn't seems to react well when -EAGAIN is > > returned, we could perhaps block on SetConfiguration since we do block > > on Acquire anyway, or you have already tried that? > > Yes, I tried it. Pulseaudio blocks communication and therefore it also > does not receive following DBus requests from bluez and so > SetConfiguration timeout. Right there are D-Bus messages when switching the endpoint, though what we could perhaps do is create the sink suspended like how it is done in case of oFono, or at least that is how I remembered it. > In fact -EAGAIN is just dropped in pulseaudio bluetooth module and > replaced by -1. I just wanted to "highlight" that part of code, so I > used -EAGAIN, but it has same meaning as any other non-zero value. > > I was thinking about it and we could block this on another layer. > pa_card_set_profile() is called when application request to change > profile via PA socket. So extend pa_card_set_profile() API to pass > callback function which would be called after profile is changed > asynchronously. And just block user request until callback is called. > > Maybe some other people who understand pulseaudio better can help? How > to implement asynchronous profile switching? > > > Another thing I noticed, we should start taking into accound the > > algorithm delay of each codec instead of adding a fixed delay of 25 > > ms, in fact 25 ms seems wrong even for SBC since it has about 5 ms of > > delay not 25 ms. > > Yes, this is something I wanted to start addressing. aptX has fixed > delay of 90 samples. Do you have some pointer there can be that delay > configured? Or where is that fixed delay hardcoded? It is hardcoded in FIXED_LATENCY_PLAYBACK_A2DP which is added like this: pa_sink_set_fixed_latency_within_thread(u->sink, (pa_bluetooth_profile_is_a2dp(u->profile) ? FIXED_LATENCY_PLAYBACK_A2DP : FIXED_LATENCY_PLAYBACK_SCO) + pa_bytes_to_usec(u->write_block_size, &u->encoder_sample_spec)); Perhaps that was used to compensate the transmission latency, but that would be different for SCO and A2DP, but I tried with just 5 ms and it seems to work pretty well: I: [lt-pulseaudio] protocol-native.c: Final latency 100.00 ms = 25.01 ms + 2*24.99 ms + 25.01 ms As oppose to something like 140 ms which the original code produces. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
Hi Pali, On Thu, Jan 24, 2019 at 1:16 AM Pali Rohár wrote: > > On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > > faststream there seems to be some problem somewhere as it does seems > > to consume too much cpu time. > > Problem is with encoding or decoding? And with main (music) channel or > with voice backchannel? Don't know really, it might be the encoding part but for the channel I don't know Ive only used the UI to test the left and right and that caused PA cpu load to spike. -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > faststream there seems to be some problem somewhere as it does seems > to consume too much cpu time. Problem is with encoding or decoding? And with main (music) channel or with voice backchannel? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
On Wednesday 23 January 2019 19:16:16 Luiz Augusto von Dentz wrote: > Hi Pali, > On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > > > I think that this patch series is now ready for review and testing. All > > needed parts are finished. > > > > The only problem is with asynchronous profile switching as function > > pa_card_set_profile() does not support it. All details are in patch > > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > > > So can you look at this patch series and review it? > > I tested this today, it seems to work fine with sbc but with > faststream there seems to be some problem somewhere as it does seems > to consume too much cpu time. Regarding set_profile that is something > I think we will need to address otherwise the UI is pretty much > useless to switch as it doesn't seems to react well when -EAGAIN is > returned, we could perhaps block on SetConfiguration since we do block > on Acquire anyway, or you have already tried that? Yes, I tried it. Pulseaudio blocks communication and therefore it also does not receive following DBus requests from bluez and so SetConfiguration timeout. In fact -EAGAIN is just dropped in pulseaudio bluetooth module and replaced by -1. I just wanted to "highlight" that part of code, so I used -EAGAIN, but it has same meaning as any other non-zero value. I was thinking about it and we could block this on another layer. pa_card_set_profile() is called when application request to change profile via PA socket. So extend pa_card_set_profile() API to pass callback function which would be called after profile is changed asynchronously. And just block user request until callback is called. Maybe some other people who understand pulseaudio better can help? How to implement asynchronous profile switching? > Another thing I noticed, we should start taking into accound the > algorithm delay of each codec instead of adding a fixed delay of 25 > ms, in fact 25 ms seems wrong even for SBC since it has about 5 ms of > delay not 25 ms. Yes, this is something I wanted to start addressing. aptX has fixed delay of 90 samples. Do you have some pointer there can be that delay configured? Or where is that fixed delay hardcoded? > I will do a proper review of each patch tomorrow, but for a user point > of view I thing these details matter the most. > > > On Saturday 19 January 2019 18:11:49 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. > > > > > > With this new modular API it should be easy to add other codec support > > > like MP3, AAC or LDAC. > > > > > > API is designed also for ability to register "more variants" or one > > > A2DP codec. E.g. SBC codec forced to high quality, SBC codec forced > > > to low quality, SBC codec with automatic quality. > > > > > > Once we agree on final version of codec API, I can prepare patches > > > also for choosing above SBC codec quality. > > > > > > I tested playback with SBC, aptX and FastStream codecs and it is > > > working fine. Also microphone voice in FastStream is working and has > > > slightly better quality as in HSP profile. > > > > > > Changes in v5: > > > * Added support for switching between A2DP codec via profiles. > > > This requires bluez patches from above link. > > > > > > Changes in v4: > > > * Added support for aptX HD codec > > > * Changed codec API for reading block size and reducing encoder bitrate > > > * Added support for microphone backchannel into module-bluez5-device > > > * Added support for microphone backchannel into FastStream codec > > > * Fixed parsing FastStream A2DP config buffer > > > * Fixed validation for config buffers > > > * Fixed calculating block size for aptX codec > > > * Fixed resetting SBC and FastStream codecs > > > > > > Changes in v3: > > > * Fix
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
Hi Pali, On Sat, Jan 19, 2019 at 7:19 PM Pali Rohár wrote: > > I think that this patch series is now ready for review and testing. All > needed parts are finished. > > The only problem is with asynchronous profile switching as function > pa_card_set_profile() does not support it. All details are in patch > "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". > > So can you look at this patch series and review it? I tested this today, it seems to work fine with sbc but with faststream there seems to be some problem somewhere as it does seems to consume too much cpu time. Regarding set_profile that is something I think we will need to address otherwise the UI is pretty much useless to switch as it doesn't seems to react well when -EAGAIN is returned, we could perhaps block on SetConfiguration since we do block on Acquire anyway, or you have already tried that? Another thing I noticed, we should start taking into accound the algorithm delay of each codec instead of adding a fixed delay of 25 ms, in fact 25 ms seems wrong even for SBC since it has about 5 ms of delay not 25 ms. I will do a proper review of each patch tomorrow, but for a user point of view I thing these details matter the most. > On Saturday 19 January 2019 18:11:49 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. > > > > With this new modular API it should be easy to add other codec support > > like MP3, AAC or LDAC. > > > > API is designed also for ability to register "more variants" or one > > A2DP codec. E.g. SBC codec forced to high quality, SBC codec forced > > to low quality, SBC codec with automatic quality. > > > > Once we agree on final version of codec API, I can prepare patches > > also for choosing above SBC codec quality. > > > > I tested playback with SBC, aptX and FastStream codecs and it is > > working fine. Also microphone voice in FastStream is working and has > > slightly better quality as in HSP profile. > > > > Changes in v5: > > * Added support for switching between A2DP codec via profiles. > > This requires bluez patches from above link. > > > > Changes in v4: > > * Added support for aptX HD codec > > * Changed codec API for reading block size and reducing encoder bitrate > > * Added support for microphone backchannel into module-bluez5-device > > * Added support for microphone backchannel into FastStream codec > > * Fixed parsing FastStream A2DP config buffer > > * Fixed validation for config buffers > > * Fixed calculating block size for aptX codec > > * Fixed resetting SBC and FastStream codecs > > > > Changes in v3: > > * Fixed problems pointed by Tanu > > > > Pali Rohár (7): > > switch-on-port-available: Fix null pointer dereference > > bluetooth: policy: Remove BlueZ 4 related code > > bluetooth: policy: Reflect a2dp profile names > > bluetooth: Update a2dp-codecs.h from upstream bluez project > > bluetooth: Modular API for A2DP codecs > > bluetooth: Add A2DP aptX and aptX HD codecs support > > bluetooth: Add A2DP FastStream codec support > > > > configure.ac| 36 + > > src/Makefile.am | 20 +- > > src/modules/bluetooth/a2dp-codec-api.h | 80 +++ > > src/modules/bluetooth/a2dp-codec-aptx.c | 547 +++ > > src/modules/bluetooth/a2dp-codec-faststream.c | 433 > > src/modules/bluetooth/a2dp-codec-sbc.c | 638 + > > src/modules/bluetooth/a2dp-codec-util.c | 66 ++ > > src/modules/bluetooth/a2dp-codec-util.h | 34 + > > src/modules/bluetooth/a2dp-codecs.h | 354 +- > > src/modules/bluetooth/bluez5-util.c | 768 +--- > > src/modules/bluetooth/bluez5-util.h | 40 +- > > src/modules/bluetooth/module-bluetooth-po
Re: [pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
I think that this patch series is now ready for review and testing. All needed parts are finished. The only problem is with asynchronous profile switching as function pa_card_set_profile() does not support it. All details are in patch "[PATCH v5 5/7] bluetooth: Modular API for A2DP codecs". So can you look at this patch series and review it? On Saturday 19 January 2019 18:11:49 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. > > With this new modular API it should be easy to add other codec support > like MP3, AAC or LDAC. > > API is designed also for ability to register "more variants" or one > A2DP codec. E.g. SBC codec forced to high quality, SBC codec forced > to low quality, SBC codec with automatic quality. > > Once we agree on final version of codec API, I can prepare patches > also for choosing above SBC codec quality. > > I tested playback with SBC, aptX and FastStream codecs and it is > working fine. Also microphone voice in FastStream is working and has > slightly better quality as in HSP profile. > > Changes in v5: > * Added support for switching between A2DP codec via profiles. > This requires bluez patches from above link. > > Changes in v4: > * Added support for aptX HD codec > * Changed codec API for reading block size and reducing encoder bitrate > * Added support for microphone backchannel into module-bluez5-device > * Added support for microphone backchannel into FastStream codec > * Fixed parsing FastStream A2DP config buffer > * Fixed validation for config buffers > * Fixed calculating block size for aptX codec > * Fixed resetting SBC and FastStream codecs > > Changes in v3: > * Fixed problems pointed by Tanu > > Pali Rohár (7): > switch-on-port-available: Fix null pointer dereference > bluetooth: policy: Remove BlueZ 4 related code > bluetooth: policy: Reflect a2dp profile names > bluetooth: Update a2dp-codecs.h from upstream bluez project > bluetooth: Modular API for A2DP codecs > bluetooth: Add A2DP aptX and aptX HD codecs support > bluetooth: Add A2DP FastStream codec support > > configure.ac| 36 + > src/Makefile.am | 20 +- > src/modules/bluetooth/a2dp-codec-api.h | 80 +++ > src/modules/bluetooth/a2dp-codec-aptx.c | 547 +++ > src/modules/bluetooth/a2dp-codec-faststream.c | 433 > src/modules/bluetooth/a2dp-codec-sbc.c | 638 + > src/modules/bluetooth/a2dp-codec-util.c | 66 ++ > src/modules/bluetooth/a2dp-codec-util.h | 34 + > src/modules/bluetooth/a2dp-codecs.h | 354 +- > src/modules/bluetooth/bluez5-util.c | 768 +--- > src/modules/bluetooth/bluez5-util.h | 40 +- > src/modules/bluetooth/module-bluetooth-policy.c | 19 +- > src/modules/bluetooth/module-bluez5-device.c| 884 > +++- > src/modules/module-switch-on-port-available.c | 2 +- > 14 files changed, 3181 insertions(+), 740 deletions(-) > create mode 100644 src/modules/bluetooth/a2dp-codec-api.h > create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c > create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c > create mode 100644 src/modules/bluetooth/a2dp-codec-sbc.c > create mode 100644 src/modules/bluetooth/a2dp-codec-util.c > create mode 100644 src/modules/bluetooth/a2dp-codec-util.h -- Pali Rohár pali.ro...@gmail.com signature.asc Description: PGP signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH v5 0/7] New API for Bluetooth A2DP codecs
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. With this new modular API it should be easy to add other codec support like MP3, AAC or LDAC. API is designed also for ability to register "more variants" or one A2DP codec. E.g. SBC codec forced to high quality, SBC codec forced to low quality, SBC codec with automatic quality. Once we agree on final version of codec API, I can prepare patches also for choosing above SBC codec quality. I tested playback with SBC, aptX and FastStream codecs and it is working fine. Also microphone voice in FastStream is working and has slightly better quality as in HSP profile. Changes in v5: * Added support for switching between A2DP codec via profiles. This requires bluez patches from above link. Changes in v4: * Added support for aptX HD codec * Changed codec API for reading block size and reducing encoder bitrate * Added support for microphone backchannel into module-bluez5-device * Added support for microphone backchannel into FastStream codec * Fixed parsing FastStream A2DP config buffer * Fixed validation for config buffers * Fixed calculating block size for aptX codec * Fixed resetting SBC and FastStream codecs Changes in v3: * Fixed problems pointed by Tanu Pali Rohár (7): switch-on-port-available: Fix null pointer dereference bluetooth: policy: Remove BlueZ 4 related code bluetooth: policy: Reflect a2dp profile names bluetooth: Update a2dp-codecs.h from upstream bluez project bluetooth: Modular API for A2DP codecs bluetooth: Add A2DP aptX and aptX HD codecs support bluetooth: Add A2DP FastStream codec support configure.ac| 36 + src/Makefile.am | 20 +- src/modules/bluetooth/a2dp-codec-api.h | 80 +++ src/modules/bluetooth/a2dp-codec-aptx.c | 547 +++ src/modules/bluetooth/a2dp-codec-faststream.c | 433 src/modules/bluetooth/a2dp-codec-sbc.c | 638 + src/modules/bluetooth/a2dp-codec-util.c | 66 ++ src/modules/bluetooth/a2dp-codec-util.h | 34 + src/modules/bluetooth/a2dp-codecs.h | 354 +- src/modules/bluetooth/bluez5-util.c | 768 +--- src/modules/bluetooth/bluez5-util.h | 40 +- src/modules/bluetooth/module-bluetooth-policy.c | 19 +- src/modules/bluetooth/module-bluez5-device.c| 884 +++- src/modules/module-switch-on-port-available.c | 2 +- 14 files changed, 3181 insertions(+), 740 deletions(-) create mode 100644 src/modules/bluetooth/a2dp-codec-api.h create mode 100644 src/modules/bluetooth/a2dp-codec-aptx.c create mode 100644 src/modules/bluetooth/a2dp-codec-faststream.c create mode 100644 src/modules/bluetooth/a2dp-codec-sbc.c create mode 100644 src/modules/bluetooth/a2dp-codec-util.c create mode 100644 src/modules/bluetooth/a2dp-codec-util.h -- 2.11.0 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
