bluez - check for new a2dp features

bluez - check for new a2dp features

[Pali Rohár]

[-- 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 --]

Re: bluez - check for new a2dp features

[Pali Rohár]

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

Re: bluez - check for new a2dp features

[Luiz Augusto von Dentz]

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

Re: bluez - check for new a2dp features

[Pali Rohár]

[-- 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 --]

Re: bluez - check for new a2dp features

[Luiz Augusto von Dentz]

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

Re: bluez - check for new a2dp features

[Pali Rohár]

[-- 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 --]

Re: bluez - check for new a2dp features

[Pali Rohár]

[-- 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 --]

Re: bluez - check for new a2dp features

[Pali Rohár]

[-- 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 --]

Re: bluez - check for new a2dp features

[Luiz Augusto von Dentz]

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

Re: bluez - check for new a2dp features

[Pali Rohár]

[-- 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 --]

Re: bluez - check for new a2dp features

[Pali Rohár]

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

Re: bluez - check for new a2dp features

[Luiz Augusto von Dentz]

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

Re: bluez - check for new a2dp features

[Pali Rohár]

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