* bluez - check for new a2dp features @ 2019-05-13 17:05 Pali Rohár 2019-06-07 12:58 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-05-13 17:05 UTC (permalink / raw) To: linux-bluetooth, Luiz Augusto von Dentz [-- Attachment #1: Type: text/plain, Size: 932 bytes --] Hello! In current git bluez master repository are new features related to A2DP. E.g. support for codec switching or fallback to other local dbus endpoints when current selected rejected connection... Moreover codec switching support is behind experimental runtime switch. For pulseaudio a2dp module I need to do runtime check if above features are supported by currently running bluez instance (which registered to dbus org.bluez. It is needed to ensure that pulseaudio does not introduce regression for older bluez version without above new A2DP features. But currently I have not found any way how to detect if bluez supports codec switching or if it has support for trying another local SEP for connection. So, could you please export e.g. bluez version as dbus property? And also property if codec switching is supported and enabled by that experimental flag? -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-05-13 17:05 bluez - check for new a2dp features Pali Rohár @ 2019-06-07 12:58 ` Pali Rohár 2019-06-07 15:26 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-06-07 12:58 UTC (permalink / raw) To: linux-bluetooth, Luiz Augusto von Dentz On Monday 13 May 2019 19:05:50 Pali Rohár wrote: > Hello! > > In current git bluez master repository are new features related to A2DP. > E.g. support for codec switching or fallback to other local dbus > endpoints when current selected rejected connection... > > Moreover codec switching support is behind experimental runtime switch. > > For pulseaudio a2dp module I need to do runtime check if above features > are supported by currently running bluez instance (which registered to > dbus org.bluez. It is needed to ensure that pulseaudio does not > introduce regression for older bluez version without above new A2DP > features. > > But currently I have not found any way how to detect if bluez supports > codec switching or if it has support for trying another local SEP for > connection. > > So, could you please export e.g. bluez version as dbus property? And > also property if codec switching is supported and enabled by that > experimental flag? Hello, I would like to ask for some possibility to export these information. Without them it is not really possible to have stable implementation which would work with both old and new bluez version. -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-07 12:58 ` Pali Rohár @ 2019-06-07 15:26 ` Luiz Augusto von Dentz 2019-06-07 15:37 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Luiz Augusto von Dentz @ 2019-06-07 15:26 UTC (permalink / raw) To: Pali Rohár; +Cc: linux-bluetooth Hi Pali, On Fri, Jun 7, 2019 at 3:58 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > On Monday 13 May 2019 19:05:50 Pali Rohár wrote: > > Hello! > > > > In current git bluez master repository are new features related to A2DP. > > E.g. support for codec switching or fallback to other local dbus > > endpoints when current selected rejected connection... > > > > Moreover codec switching support is behind experimental runtime switch. > > > > For pulseaudio a2dp module I need to do runtime check if above features > > are supported by currently running bluez instance (which registered to > > dbus org.bluez. It is needed to ensure that pulseaudio does not > > introduce regression for older bluez version without above new A2DP > > features. > > > > But currently I have not found any way how to detect if bluez supports > > codec switching or if it has support for trying another local SEP for > > connection. > > > > So, could you please export e.g. bluez version as dbus property? And > > also property if codec switching is supported and enabled by that > > experimental flag? > > Hello, I would like to ask for some possibility to export these > information. Without them it is not really possible to have stable > implementation which would work with both old and new bluez version. I wonder what you are talking about since your changes do have checks for when endpoints are detected, isn't that enough to detect if one can switch codecs or not? This logic used to work just fine last time I tested it. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-07 15:26 ` Luiz Augusto von Dentz @ 2019-06-07 15:37 ` Pali Rohár 2019-06-08 10:56 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-06-07 15:37 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 2300 bytes --] On Friday 07 June 2019 18:26:02 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Fri, Jun 7, 2019 at 3:58 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > > > On Monday 13 May 2019 19:05:50 Pali Rohár wrote: > > > Hello! > > > > > > In current git bluez master repository are new features related to A2DP. > > > E.g. support for codec switching or fallback to other local dbus > > > endpoints when current selected rejected connection... > > > > > > Moreover codec switching support is behind experimental runtime switch. > > > > > > For pulseaudio a2dp module I need to do runtime check if above features > > > are supported by currently running bluez instance (which registered to > > > dbus org.bluez. It is needed to ensure that pulseaudio does not > > > introduce regression for older bluez version without above new A2DP > > > features. > > > > > > But currently I have not found any way how to detect if bluez supports > > > codec switching or if it has support for trying another local SEP for > > > connection. > > > > > > So, could you please export e.g. bluez version as dbus property? And > > > also property if codec switching is supported and enabled by that > > > experimental flag? > > > > Hello, I would like to ask for some possibility to export these > > information. Without them it is not really possible to have stable > > implementation which would work with both old and new bluez version. > > I wonder what you are talking about since your changes do have checks > for when endpoints are detected, But this does not work as endpoints are available on DBus only when A2DP connection is active. I already asked to export them always (even when A2DP is not connected). Main problem is that when profile switching is not available, there should be registered only one A2DP codec (SBC in automatic quality) as changing is not possible. This is to prevent introducing any regression or having registered codec which would not work correctly. > isn't that enough to detect if one can switch codecs or not? Yes, this could be enough... but endpoints on DBus must be always available, not only when A2DP profile is connected. > This logic used to work just fine last time I tested it. -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-07 15:37 ` Pali Rohár @ 2019-06-08 10:56 ` Luiz Augusto von Dentz 2019-06-08 10:59 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Luiz Augusto von Dentz @ 2019-06-08 10:56 UTC (permalink / raw) To: Pali Rohár; +Cc: linux-bluetooth Hi Pali, On Fri, Jun 7, 2019 at 6:37 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > On Friday 07 June 2019 18:26:02 Luiz Augusto von Dentz wrote: > > Hi Pali, > > > > On Fri, Jun 7, 2019 at 3:58 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > > > > > On Monday 13 May 2019 19:05:50 Pali Rohár wrote: > > > > Hello! > > > > > > > > In current git bluez master repository are new features related to A2DP. > > > > E.g. support for codec switching or fallback to other local dbus > > > > endpoints when current selected rejected connection... > > > > > > > > Moreover codec switching support is behind experimental runtime switch. > > > > > > > > For pulseaudio a2dp module I need to do runtime check if above features > > > > are supported by currently running bluez instance (which registered to > > > > dbus org.bluez. It is needed to ensure that pulseaudio does not > > > > introduce regression for older bluez version without above new A2DP > > > > features. > > > > > > > > But currently I have not found any way how to detect if bluez supports > > > > codec switching or if it has support for trying another local SEP for > > > > connection. > > > > > > > > So, could you please export e.g. bluez version as dbus property? And > > > > also property if codec switching is supported and enabled by that > > > > experimental flag? > > > > > > Hello, I would like to ask for some possibility to export these > > > information. Without them it is not really possible to have stable > > > implementation which would work with both old and new bluez version. > > > > I wonder what you are talking about since your changes do have checks > > for when endpoints are detected, > > But this does not work as endpoints are available on DBus only when A2DP > connection is active. I already asked to export them always (even when > A2DP is not connected). > > Main problem is that when profile switching is not available, there > should be registered only one A2DP codec (SBC in automatic quality) as > changing is not possible. This is to prevent introducing any regression > or having registered codec which would not work correctly. I fill like repeating myself over and over, but here it goes again, endpoints are not supposed to initiate connection which is the reason why in PA the card is created only when a profile is connected, and no we are not going to introduce feature like this to counter bugs where HFP is left connect while A2DP isn't, etc. It is very important to note that while we are caching the remote endpoints we never assume they are valid before we connect and confirm they are still available. > > isn't that enough to detect if one can switch codecs or not? > > Yes, this could be enough... but endpoints on DBus must be always > available, not only when A2DP profile is connected. Not gonna happen. > > This logic used to work just fine last time I tested it. > > -- > Pali Rohár > pali.rohar@gmail.com -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-08 10:56 ` Luiz Augusto von Dentz @ 2019-06-08 10:59 ` Pali Rohár 2019-06-08 11:15 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-06-08 10:59 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 3443 bytes --] On Saturday 08 June 2019 13:56:29 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Fri, Jun 7, 2019 at 6:37 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > > > On Friday 07 June 2019 18:26:02 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > > > > On Fri, Jun 7, 2019 at 3:58 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > > > > > > > On Monday 13 May 2019 19:05:50 Pali Rohár wrote: > > > > > Hello! > > > > > > > > > > In current git bluez master repository are new features related to A2DP. > > > > > E.g. support for codec switching or fallback to other local dbus > > > > > endpoints when current selected rejected connection... > > > > > > > > > > Moreover codec switching support is behind experimental runtime switch. > > > > > > > > > > For pulseaudio a2dp module I need to do runtime check if above features > > > > > are supported by currently running bluez instance (which registered to > > > > > dbus org.bluez. It is needed to ensure that pulseaudio does not > > > > > introduce regression for older bluez version without above new A2DP > > > > > features. > > > > > > > > > > But currently I have not found any way how to detect if bluez supports > > > > > codec switching or if it has support for trying another local SEP for > > > > > connection. > > > > > > > > > > So, could you please export e.g. bluez version as dbus property? And > > > > > also property if codec switching is supported and enabled by that > > > > > experimental flag? > > > > > > > > Hello, I would like to ask for some possibility to export these > > > > information. Without them it is not really possible to have stable > > > > implementation which would work with both old and new bluez version. > > > > > > I wonder what you are talking about since your changes do have checks > > > for when endpoints are detected, > > > > But this does not work as endpoints are available on DBus only when A2DP > > connection is active. I already asked to export them always (even when > > A2DP is not connected). > > > > Main problem is that when profile switching is not available, there > > should be registered only one A2DP codec (SBC in automatic quality) as > > changing is not possible. This is to prevent introducing any regression > > or having registered codec which would not work correctly. > > I fill like repeating myself over and over, but here it goes again, > endpoints are not supposed to initiate connection which is the reason > why in PA the card is created only when a profile is connected, and no > we are not going to introduce feature like this to counter bugs where > HFP is left connect while A2DP isn't, etc. It is very important to > note that while we are caching the remote endpoints we never assume > they are valid before we connect and confirm they are still available. 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? > > > isn't that enough to detect if one can switch codecs or not? > > > > Yes, this could be enough... but endpoints on DBus must be always > > available, not only when A2DP profile is connected. > > Not gonna happen. > > > > This logic used to work just fine last time I tested it. > > > > -- > > Pali Rohár > > pali.rohar@gmail.com > > > -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-08 10:59 ` Pali Rohár @ 2019-06-08 11:15 ` Pali Rohár 2019-06-22 16:18 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-06-08 11:15 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 1640 bytes --] 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. -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-08 11:15 ` Pali Rohár @ 2019-06-22 16:18 ` Pali Rohár 2019-06-22 17:01 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-06-22 16:18 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 2302 bytes --] 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. -- Pali Rohár pali.rohar@gmail.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-22 16:18 ` Pali Rohár @ 2019-06-22 17:01 ` Luiz Augusto von Dentz 2019-06-22 17:09 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Luiz Augusto von Dentz @ 2019-06-22 17:01 UTC (permalink / raw) To: Pali Rohár; +Cc: linux-bluetooth Hi Pali, On Sat, Jun 22, 2019 at 7:18 PM Pali Rohár <pali.rohar@gmail.com> 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. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-22 17:01 ` Luiz Augusto von Dentz @ 2019-06-22 17:09 ` Pali Rohár 2019-07-03 12:56 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-06-22 17:09 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth [-- Attachment #1: Type: text/plain, Size: 3661 bytes --] 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@gmail.com> 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@gmail.com [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-06-22 17:09 ` Pali Rohár @ 2019-07-03 12:56 ` Pali Rohár 2019-07-03 13:26 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 13+ messages in thread From: Pali Rohár @ 2019-07-03 12:56 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On Saturday 22 June 2019 19:09:33 Pali Rohár wrote: > On Saturday 22 June 2019 20:01:15 Luiz Augusto von Dentz wrote: > > Hi Pali, > > > > 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. Hi Luiz! Do you have some patches ready for testing? -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-07-03 12:56 ` Pali Rohár @ 2019-07-03 13:26 ` Luiz Augusto von Dentz 2019-07-03 13:30 ` Pali Rohár 0 siblings, 1 reply; 13+ messages in thread From: Luiz Augusto von Dentz @ 2019-07-03 13:26 UTC (permalink / raw) To: Pali Rohár; +Cc: linux-bluetooth Hi Pali, On Wed, Jul 3, 2019 at 3:56 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > On Saturday 22 June 2019 19:09:33 Pali Rohár wrote: > > On Saturday 22 June 2019 20:01:15 Luiz Augusto von Dentz wrote: > > > Hi Pali, > > > > > > 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. > > Hi Luiz! Do you have some patches ready for testing? Not yet, will try to arrange time for implementing it next week. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: bluez - check for new a2dp features 2019-07-03 13:26 ` Luiz Augusto von Dentz @ 2019-07-03 13:30 ` Pali Rohár 0 siblings, 0 replies; 13+ messages in thread From: Pali Rohár @ 2019-07-03 13:30 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On Wednesday 03 July 2019 16:26:37 Luiz Augusto von Dentz wrote: > Hi Pali, > > On Wed, Jul 3, 2019 at 3:56 PM Pali Rohár <pali.rohar@gmail.com> wrote: > > > > On Saturday 22 June 2019 19:09:33 Pali Rohár wrote: > > > On Saturday 22 June 2019 20:01:15 Luiz Augusto von Dentz wrote: > > > > Hi Pali, > > > > > > > > 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. > > > > Hi Luiz! Do you have some patches ready for testing? > > Not yet, will try to arrange time for implementing it next week. Ok, I will wait for them. -- Pali Rohár pali.rohar@gmail.com ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-07-03 13:30 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-05-13 17:05 bluez - check for new a2dp features Pali Rohár 2019-06-07 12:58 ` Pali Rohár 2019-06-07 15:26 ` Luiz Augusto von Dentz 2019-06-07 15:37 ` Pali Rohár 2019-06-08 10:56 ` Luiz Augusto von Dentz 2019-06-08 10:59 ` Pali Rohár 2019-06-08 11:15 ` Pali Rohár 2019-06-22 16:18 ` Pali Rohár 2019-06-22 17:01 ` Luiz Augusto von Dentz 2019-06-22 17:09 ` Pali Rohár 2019-07-03 12:56 ` Pali Rohár 2019-07-03 13:26 ` Luiz Augusto von Dentz 2019-07-03 13:30 ` Pali Rohár
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).