On Saturday 22 June 2019 20:01:15 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Sat, Jun 22, 2019 at 7:18 PM Pali Rohár <pali.rohar@xxxxxxxxx> wrote: > > > > On Saturday 08 June 2019 13:15:53 Pali Rohár wrote: > > > On Saturday 08 June 2019 12:59:24 Pali Rohár wrote: > > > > Ok. So is there any way how to check if bluez supports profile switching > > > > or not? And if not, could be introduced some flag/property on DBus so > > > > applications would not this information? > > > > > > Because older versions of bluez does not support profile switching and > > > does not support properly remembering last used SEP, I need to know this > > > information in pulseaudio. To prevent any breakage e.g. that high > > > bandwidth codec would be chosen by old version of bluez in unsuitable > > > environment. Because of these problems I do not think that pulseaudio > > > should register these high quality codec with fixed high bandwidth. And > > > currently there is no way (or at last I do not know) how to check if > > > bluez support these features. And I need to know it at time when > > > pulseaudio is registering to DBus so it would correctly decide if SBC > > > UHQ codec should be registered via DBus to bluez or not. > > > > > > Currently I know one way how to detect it -- look if there are available > > > SEP paths at dbus. But this works only after A2DP connection is active. > > > So I cannot use this "heuristic". > > > > > > Therefore I'm asking for some DBus property or flag or whatever which > > > would tell me, prior to registering A2DP codecs via DBus to bluez, if > > > bluez supports profile switching or not. > > > > > > Without this information, pulseaudio could enter into state when it is > > > unable to transmit any audio via bluetooth because old bluez chosen > > > unsuitable codec. And because old bluez version does not support profile > > > switching, nobody (pulseaudio or user) is able to fix this problem. > > > > Would be possible to provide this runtime dbus information? As explained > > in previous email, I really need it for pulseaudio for additional A2DP > > codec support. > > > > If not, then I would be forced to use compile time check (probably via > > bluez.pc) and based on this decide if support for additional codecs and > > profile switching would be compiled into pulseaudio or not... But this > > would work only in case whole profile switching would not be hidden > > under --experimental command line flag. So another configure flag for > > pulseaudio would be needed. > > I think a better idea would be that we introduce something specific to > that, such as the SEID being returned so the next time around you may > restore a SEID, this may actually make more sense perhaps if we reuse > the RegisterApplication semantics: > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n464 > > That means it is no longer required to call RegisterEndpoint as many > times as there are endpoints since that is time-consuming due to the > D-Bus round trips, instead, the endpoint are discovered with the use > of ObjectManager, if the method doesn't exist then you just fall back > to the old mechanism since it might be an old daemon. Hi! If I understand it correctly, pulseaudio would register itself via new dbus method and bluez daemon then discover A2DP SEP endpoints automatically, right? And if that new dbus method does not exist pulseaudio would know that in system is running old bluez version without codec switching support. Seems it is perfectly fine solution. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
