Determinate EDR speed

Determinate EDR speed

[Pali Rohár]

Hello!

I would like to ask, how can userspace application which uses bluez DBus
API determinate EDR speed of remote bluetooth device?

Particularly, I'm interested in detection if bluetooth headset supports
EDR 2 Mbps or EDR 3 Mbps speed and based on this decide which SBC
parameters would be used for encoding audio via SBC codec.

Is there any bluez API for it?

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Determinate EDR speed

[Gix, Brian]

Hi Pali,

On Fri, 2019-10-11 at 10:27 +0200, Pali Rohár wrote:
> Hello!
> 
> I would like to ask, how can userspace application which uses bluez DBus
> API determinate EDR speed of remote bluetooth device?
> 
> Particularly, I'm interested in detection if bluetooth headset supports
> EDR 2 Mbps or EDR 3 Mbps speed and based on this decide which SBC
> parameters would be used for encoding audio via SBC codec.

There are a variety of things that can affect real-time throughput, and I think even EDR 2 vs 3 might
dynamically change to fit the current conditions.  If you have the ability to have fine control of the SBC
parameters, I think the *best* way to adjust for throughput is to choose what sample rate and subands you
want, and then squeeze or expand the bitpool to fit your throughput. (bitpool is something that can be
dynamically adjusted, I believe, without re-negotiation).

Howeverever, the real question is how to tell what the instantaneous realtime throughput is...  which is
certainly affected by support for EDR2 vs EDR3, but is also affected by distance, RSSI, environmental RF, and
what the other L2CAP channels on the connection are carrying (AVRCP for example).

I don't think a simple boolean for EDR2 and/or EDR3, especially in user space, is going to give you the level
of information you need.

> 
> Is there any bluez API for it?
> 

Re: Determinate EDR speed

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

Hi!

On Friday 11 October 2019 18:15:47 Gix, Brian wrote:
> Hi Pali,
> 
> On Fri, 2019-10-11 at 10:27 +0200, Pali Rohár wrote:
> > Hello!
> > 
> > I would like to ask, how can userspace application which uses bluez DBus
> > API determinate EDR speed of remote bluetooth device?
> > 
> > Particularly, I'm interested in detection if bluetooth headset supports
> > EDR 2 Mbps or EDR 3 Mbps speed and based on this decide which SBC
> > parameters would be used for encoding audio via SBC codec.
> 
> There are a variety of things that can affect real-time throughput, and I think even EDR 2 vs 3 might
> dynamically change to fit the current conditions.  If you have the ability to have fine control of the SBC
> parameters, I think the *best* way to adjust for throughput is to choose what sample rate and subands you
> want, and then squeeze or expand the bitpool to fit your throughput. (bitpool is something that can be
> dynamically adjusted, I believe, without re-negotiation).

I know about all SBC parameters, I'm implementing/improving SBC codec
support in pulseaudio, de-facto standard way how current Linux desktop
system can do playback via bluetooth/bluez.

I'm already using fixed SBC subbands and sample rate based on pulseaudio
source. And SBC bitpool is really the thing which I want to choose based
on EDR 2 vs 3 availability.

ValdikSS (CCed) created a nice calculator for SBC codec parameters and
via it you can easily calculate which bitpool values you want to use to
minimize wasted bytes in bluetooth frames. But to do it, you need to
know MTU resp. information if device supports EDR 2 or EDR 3.

https://btcodecs.valdikss.org.ru/sbc-bitrate-calculator/

> Howeverever, the real question is how to tell what the instantaneous realtime throughput is...  which is
> certainly affected by support for EDR2 vs EDR3, but is also affected by distance, RSSI, environmental RF, and
> what the other L2CAP channels on the connection are carrying (AVRCP for example).
> 
> I don't think a simple boolean for EDR2 and/or EDR3, especially in user space, is going to give you the level
> of information you need.

Currently bluez API, method Acquire() already inform called application
what is socket MTU for input and output. So from this information it is
possible to detect if device supports EDR 3 or not.

But it is too late to have this information. I need to send SBC
parameters to bluez first when doing A2DP negotiation, this is early
steps before Acquire() is called.

Therefore I'm asking for some way how to get information if device
supports EDR 2 or EDR 3. This is basically requirement for proper
implementation of SBC in high quality mode. So if there are not such API
yet, could it be exported from kernel to userspace and bluetoothd
daemon?

See these two articles for more details about SBC and its high quality:

https://habr.com/en/post/456182/
http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec

> > 
> > Is there any bluez API for it?
> > 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Determinate EDR speed

[Gix, Brian]

Hi Pali,

On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> Currently bluez API, method Acquire() already inform called application
> what is socket MTU for input and output. So from this information it is
> possible to detect if device supports EDR 3 or not.
> 
> But it is too late to have this information. I need to send SBC
> parameters to bluez first when doing A2DP negotiation, this is early
> steps before Acquire() is called.

This seems to be the kind of information which is fixed, for the life of the pairing.

What if you assumed the lower speed the first time you connected, determined the
speed during the first streaming, and then either immediately renegotiate (caching the identifying information
of the SNK), or just cache the information for future connections.

Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.

In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
documentation.

> 
> Therefore I'm asking for some way how to get information if device
> supports EDR 2 or EDR 3. This is basically requirement for proper
> implementation of SBC in high quality mode. So if there are not such API
> yet, could it be exported from kernel to userspace and bluetoothd
> daemon?
> 
> See these two articles for more details about SBC and its high quality:
> 
> https://habr.com/en/post/456182/
> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> 
> > > Is there any bluez API for it?
> > > 

Re: Determinate EDR speed

[Gix, Brian]

On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> Hi Pali,
> 
> On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > Currently bluez API, method Acquire() already inform called application
> > what is socket MTU for input and output. So from this information it is
> > possible to detect if device supports EDR 3 or not.
> > 
> > But it is too late to have this information. I need to send SBC
> > parameters to bluez first when doing A2DP negotiation, this is early
> > steps before Acquire() is called.
> 
> This seems to be the kind of information which is fixed, for the life of the pairing.
> 
> What if you assumed the lower speed the first time you connected, determined the
> speed during the first streaming, and then either immediately renegotiate (caching the identifying
> information
> of the SNK), or just cache the information for future connections.
> 
> Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> 
> In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> documentation.

Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
your connection time perhaps, but would be less noticable to the user.

> 
> > Therefore I'm asking for some way how to get information if device
> > supports EDR 2 or EDR 3. This is basically requirement for proper
> > implementation of SBC in high quality mode. So if there are not such API
> > yet, could it be exported from kernel to userspace and bluetoothd
> > daemon?
> > 
> > See these two articles for more details about SBC and its high quality:
> > 
> > https://habr.com/en/post/456182/
> > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > 
> > > > Is there any bluez API for it?
> > > > 

Re: Determinate EDR speed

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 2799 bytes --]

On Friday 11 October 2019 19:05:56 Gix, Brian wrote:
> On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> > Hi Pali,
> > 
> > On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > > Currently bluez API, method Acquire() already inform called application
> > > what is socket MTU for input and output. So from this information it is
> > > possible to detect if device supports EDR 3 or not.
> > > 
> > > But it is too late to have this information. I need to send SBC
> > > parameters to bluez first when doing A2DP negotiation, this is early
> > > steps before Acquire() is called.
> > 
> > This seems to be the kind of information which is fixed, for the life of the pairing.
> > 
> > What if you assumed the lower speed the first time you connected, determined the
> > speed during the first streaming, and then either immediately renegotiate (caching the identifying
> > information
> > of the SNK), or just cache the information for future connections.
> > 
> > Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> > 
> > In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> > documentation.
> 
> Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> your connection time perhaps, but would be less noticable to the user.

This increase connection time, increase complexity of implementation
(lot of things can fail) and just complicate lot of things there. Plus
adds that glitch which is not user friendly.

Also bluetooth devices, like headsets, probably do not expects that
somebody is going to do such thing and we can hit other implementation
problems...

And moreover it is just big hack and workaround for that problem. Not a
reasonable solution.

In btmon I can see it, so kernel already knows that information. Why it
cannot tell it to userspace and bluetooth daemon to client application?

Client application (e.g. pulseaudio) should really know if is going to
talk with bluetooth device with EDR 2 or EDR 3.

> > 
> > > Therefore I'm asking for some way how to get information if device
> > > supports EDR 2 or EDR 3. This is basically requirement for proper
> > > implementation of SBC in high quality mode. So if there are not such API
> > > yet, could it be exported from kernel to userspace and bluetoothd
> > > daemon?
> > > 
> > > See these two articles for more details about SBC and its high quality:
> > > 
> > > https://habr.com/en/post/456182/
> > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > > 
> > > > > Is there any bluez API for it?
> > > > > 

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Determinate EDR speed

[Luiz Augusto von Dentz]

Hi Pali,

On Fri, Oct 11, 2019 at 11:07 PM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Friday 11 October 2019 19:05:56 Gix, Brian wrote:
> > On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> > > Hi Pali,
> > >
> > > On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > > > Currently bluez API, method Acquire() already inform called application
> > > > what is socket MTU for input and output. So from this information it is
> > > > possible to detect if device supports EDR 3 or not.
> > > >
> > > > But it is too late to have this information. I need to send SBC
> > > > parameters to bluez first when doing A2DP negotiation, this is early
> > > > steps before Acquire() is called.
> > >
> > > This seems to be the kind of information which is fixed, for the life of the pairing.
> > >
> > > What if you assumed the lower speed the first time you connected, determined the
> > > speed during the first streaming, and then either immediately renegotiate (caching the identifying
> > > information
> > > of the SNK), or just cache the information for future connections.
> > >
> > > Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> > >
> > > In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> > > documentation.
> >
> > Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> > your connection time perhaps, but would be less noticable to the user.
>
> This increase connection time, increase complexity of implementation
> (lot of things can fail) and just complicate lot of things there. Plus
> adds that glitch which is not user friendly.
>
> Also bluetooth devices, like headsets, probably do not expects that
> somebody is going to do such thing and we can hit other implementation
> problems...
>
> And moreover it is just big hack and workaround for that problem. Not a
> reasonable solution.
>
> In btmon I can see it, so kernel already knows that information. Why it
> cannot tell it to userspace and bluetooth daemon to client application?
>
> Client application (e.g. pulseaudio) should really know if is going to
> talk with bluetooth device with EDR 2 or EDR 3.
>
> > >
> > > > Therefore I'm asking for some way how to get information if device
> > > > supports EDR 2 or EDR 3. This is basically requirement for proper
> > > > implementation of SBC in high quality mode. So if there are not such API
> > > > yet, could it be exported from kernel to userspace and bluetoothd
> > > > daemon?
> > > >
> > > > See these two articles for more details about SBC and its high quality:
> > > >
> > > > https://habr.com/en/post/456182/
> > > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > > >
> > > > > > Is there any bluez API for it?
> > > > > >

There quite a few assumption here that are not really how it is
implemented in BlueZ:

1. The L2CAP MTU is not based on the ACL link (should be relatively
easy to change)
2. L2CAP MTU is not required to be symmetric.
3. Since the ACL link is shared for all channels we shouldn't really
assume all throughput will be available
4. PA flow control is not just filling up packets and sending them
when they are full to maximize speed, instead it send packets when
necessary to maintain a constant speed so the MTU may not be fully
used, in fact trying to maximize the MTU may result in higher latency
since packets would be sent less frequently.

With this in mind I think the only thing we should look into is to
adjust the default L2CAP MTU to match the underline ACL Link, so it
maximizes throughput, the remote side may choose a different MTU which
will have to follow though.

-- 
Luiz Augusto von Dentz

Re: Determinate EDR speed

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 4319 bytes --]

On Saturday 12 October 2019 10:23:58 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Fri, Oct 11, 2019 at 11:07 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > On Friday 11 October 2019 19:05:56 Gix, Brian wrote:
> > > On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> > > > Hi Pali,
> > > >
> > > > On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > > > > Currently bluez API, method Acquire() already inform called application
> > > > > what is socket MTU for input and output. So from this information it is
> > > > > possible to detect if device supports EDR 3 or not.
> > > > >
> > > > > But it is too late to have this information. I need to send SBC
> > > > > parameters to bluez first when doing A2DP negotiation, this is early
> > > > > steps before Acquire() is called.
> > > >
> > > > This seems to be the kind of information which is fixed, for the life of the pairing.
> > > >
> > > > What if you assumed the lower speed the first time you connected, determined the
> > > > speed during the first streaming, and then either immediately renegotiate (caching the identifying
> > > > information
> > > > of the SNK), or just cache the information for future connections.
> > > >
> > > > Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> > > >
> > > > In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> > > > documentation.
> > >
> > > Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> > > your connection time perhaps, but would be less noticable to the user.
> >
> > This increase connection time, increase complexity of implementation
> > (lot of things can fail) and just complicate lot of things there. Plus
> > adds that glitch which is not user friendly.
> >
> > Also bluetooth devices, like headsets, probably do not expects that
> > somebody is going to do such thing and we can hit other implementation
> > problems...
> >
> > And moreover it is just big hack and workaround for that problem. Not a
> > reasonable solution.
> >
> > In btmon I can see it, so kernel already knows that information. Why it
> > cannot tell it to userspace and bluetooth daemon to client application?
> >
> > Client application (e.g. pulseaudio) should really know if is going to
> > talk with bluetooth device with EDR 2 or EDR 3.
> >
> > > >
> > > > > Therefore I'm asking for some way how to get information if device
> > > > > supports EDR 2 or EDR 3. This is basically requirement for proper
> > > > > implementation of SBC in high quality mode. So if there are not such API
> > > > > yet, could it be exported from kernel to userspace and bluetoothd
> > > > > daemon?
> > > > >
> > > > > See these two articles for more details about SBC and its high quality:
> > > > >
> > > > > https://habr.com/en/post/456182/
> > > > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > > > >
> > > > > > > Is there any bluez API for it?
> > > > > > >
> 
> There quite a few assumption here that are not really how it is
> implemented in BlueZ:
> 
> 1. The L2CAP MTU is not based on the ACL link (should be relatively
> easy to change)
> 2. L2CAP MTU is not required to be symmetric.
> 3. Since the ACL link is shared for all channels we shouldn't really
> assume all throughput will be available
> 4. PA flow control is not just filling up packets and sending them
> when they are full to maximize speed, instead it send packets when
> necessary to maintain a constant speed so the MTU may not be fully
> used, in fact trying to maximize the MTU may result in higher latency
> since packets would be sent less frequently.
> 
> With this in mind I think the only thing we should look into is to
> adjust the default L2CAP MTU to match the underline ACL Link, so it
> maximizes throughput, the remote side may choose a different MTU which
> will have to follow though.

Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
normally for distinguish for usage of SBC XQ or not. Instead of MTU I
rather need to know if device supports EDR 2 or EDR 3.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Determinate EDR speed

[Luiz Augusto von Dentz]

Hi Pali,

On Sun, Oct 13, 2019 at 10:36 AM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Saturday 12 October 2019 10:23:58 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Fri, Oct 11, 2019 at 11:07 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Friday 11 October 2019 19:05:56 Gix, Brian wrote:
> > > > On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> > > > > Hi Pali,
> > > > >
> > > > > On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > > > > > Currently bluez API, method Acquire() already inform called application
> > > > > > what is socket MTU for input and output. So from this information it is
> > > > > > possible to detect if device supports EDR 3 or not.
> > > > > >
> > > > > > But it is too late to have this information. I need to send SBC
> > > > > > parameters to bluez first when doing A2DP negotiation, this is early
> > > > > > steps before Acquire() is called.
> > > > >
> > > > > This seems to be the kind of information which is fixed, for the life of the pairing.
> > > > >
> > > > > What if you assumed the lower speed the first time you connected, determined the
> > > > > speed during the first streaming, and then either immediately renegotiate (caching the identifying
> > > > > information
> > > > > of the SNK), or just cache the information for future connections.
> > > > >
> > > > > Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> > > > >
> > > > > In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> > > > > documentation.
> > > >
> > > > Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> > > > your connection time perhaps, but would be less noticable to the user.
> > >
> > > This increase connection time, increase complexity of implementation
> > > (lot of things can fail) and just complicate lot of things there. Plus
> > > adds that glitch which is not user friendly.
> > >
> > > Also bluetooth devices, like headsets, probably do not expects that
> > > somebody is going to do such thing and we can hit other implementation
> > > problems...
> > >
> > > And moreover it is just big hack and workaround for that problem. Not a
> > > reasonable solution.
> > >
> > > In btmon I can see it, so kernel already knows that information. Why it
> > > cannot tell it to userspace and bluetooth daemon to client application?
> > >
> > > Client application (e.g. pulseaudio) should really know if is going to
> > > talk with bluetooth device with EDR 2 or EDR 3.
> > >
> > > > >
> > > > > > Therefore I'm asking for some way how to get information if device
> > > > > > supports EDR 2 or EDR 3. This is basically requirement for proper
> > > > > > implementation of SBC in high quality mode. So if there are not such API
> > > > > > yet, could it be exported from kernel to userspace and bluetoothd
> > > > > > daemon?
> > > > > >
> > > > > > See these two articles for more details about SBC and its high quality:
> > > > > >
> > > > > > https://habr.com/en/post/456182/
> > > > > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > > > > >
> > > > > > > > Is there any bluez API for it?
> > > > > > > >
> >
> > There quite a few assumption here that are not really how it is
> > implemented in BlueZ:
> >
> > 1. The L2CAP MTU is not based on the ACL link (should be relatively
> > easy to change)
> > 2. L2CAP MTU is not required to be symmetric.
> > 3. Since the ACL link is shared for all channels we shouldn't really
> > assume all throughput will be available
> > 4. PA flow control is not just filling up packets and sending them
> > when they are full to maximize speed, instead it send packets when
> > necessary to maintain a constant speed so the MTU may not be fully
> > used, in fact trying to maximize the MTU may result in higher latency
> > since packets would be sent less frequently.
> >
> > With this in mind I think the only thing we should look into is to
> > adjust the default L2CAP MTU to match the underline ACL Link, so it
> > maximizes throughput, the remote side may choose a different MTU which
> > will have to follow though.
>
> Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
> normally for distinguish for usage of SBC XQ or not. Instead of MTU I
> rather need to know if device supports EDR 2 or EDR 3.

I was trying to implement this on the kernel to match the MTU size of
L2CAP with ACL but the packet type current in use by the connection is
not exposed in the connection complete, or at least I couldn't any
reference to it, we could possibly expose the packet types via socket
option as well but changing it at runtime is probably not a good idea.

-- 
Luiz Augusto von Dentz

Re: Determinate EDR speed

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 5803 bytes --]

On Sunday 13 October 2019 11:45:58 Luiz Augusto von Dentz wrote:
> Hi Pali,
> 
> On Sun, Oct 13, 2019 at 10:36 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> >
> > On Saturday 12 October 2019 10:23:58 Luiz Augusto von Dentz wrote:
> > > Hi Pali,
> > >
> > > On Fri, Oct 11, 2019 at 11:07 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > >
> > > > On Friday 11 October 2019 19:05:56 Gix, Brian wrote:
> > > > > On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> > > > > > Hi Pali,
> > > > > >
> > > > > > On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > > > > > > Currently bluez API, method Acquire() already inform called application
> > > > > > > what is socket MTU for input and output. So from this information it is
> > > > > > > possible to detect if device supports EDR 3 or not.
> > > > > > >
> > > > > > > But it is too late to have this information. I need to send SBC
> > > > > > > parameters to bluez first when doing A2DP negotiation, this is early
> > > > > > > steps before Acquire() is called.
> > > > > >
> > > > > > This seems to be the kind of information which is fixed, for the life of the pairing.
> > > > > >
> > > > > > What if you assumed the lower speed the first time you connected, determined the
> > > > > > speed during the first streaming, and then either immediately renegotiate (caching the identifying
> > > > > > information
> > > > > > of the SNK), or just cache the information for future connections.
> > > > > >
> > > > > > Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> > > > > >
> > > > > > In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> > > > > > documentation.
> > > > >
> > > > > Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> > > > > your connection time perhaps, but would be less noticable to the user.
> > > >
> > > > This increase connection time, increase complexity of implementation
> > > > (lot of things can fail) and just complicate lot of things there. Plus
> > > > adds that glitch which is not user friendly.
> > > >
> > > > Also bluetooth devices, like headsets, probably do not expects that
> > > > somebody is going to do such thing and we can hit other implementation
> > > > problems...
> > > >
> > > > And moreover it is just big hack and workaround for that problem. Not a
> > > > reasonable solution.
> > > >
> > > > In btmon I can see it, so kernel already knows that information. Why it
> > > > cannot tell it to userspace and bluetooth daemon to client application?
> > > >
> > > > Client application (e.g. pulseaudio) should really know if is going to
> > > > talk with bluetooth device with EDR 2 or EDR 3.
> > > >
> > > > > >
> > > > > > > Therefore I'm asking for some way how to get information if device
> > > > > > > supports EDR 2 or EDR 3. This is basically requirement for proper
> > > > > > > implementation of SBC in high quality mode. So if there are not such API
> > > > > > > yet, could it be exported from kernel to userspace and bluetoothd
> > > > > > > daemon?
> > > > > > >
> > > > > > > See these two articles for more details about SBC and its high quality:
> > > > > > >
> > > > > > > https://habr.com/en/post/456182/
> > > > > > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > > > > > >
> > > > > > > > > Is there any bluez API for it?
> > > > > > > > >
> > >
> > > There quite a few assumption here that are not really how it is
> > > implemented in BlueZ:
> > >
> > > 1. The L2CAP MTU is not based on the ACL link (should be relatively
> > > easy to change)
> > > 2. L2CAP MTU is not required to be symmetric.
> > > 3. Since the ACL link is shared for all channels we shouldn't really
> > > assume all throughput will be available
> > > 4. PA flow control is not just filling up packets and sending them
> > > when they are full to maximize speed, instead it send packets when
> > > necessary to maintain a constant speed so the MTU may not be fully
> > > used, in fact trying to maximize the MTU may result in higher latency
> > > since packets would be sent less frequently.
> > >
> > > With this in mind I think the only thing we should look into is to
> > > adjust the default L2CAP MTU to match the underline ACL Link, so it
> > > maximizes throughput, the remote side may choose a different MTU which
> > > will have to follow though.
> >
> > Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
> > normally for distinguish for usage of SBC XQ or not. Instead of MTU I
> > rather need to know if device supports EDR 2 or EDR 3.
> 
> I was trying to implement this on the kernel to match the MTU size of
> L2CAP with ACL but the packet type current in use by the connection is
> not exposed in the connection complete, or at least I couldn't any
> reference to it, we could possibly expose the packet types via socket
> option as well but changing it at runtime is probably not a good idea.

Hello, when I run btmon, I see following information very early before
creating A2DP connection:

HCI Event: Read Remote Supported Features (0x0b) plen 11
        Status: Success (0x00)
        Handle: 35
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
          ...
          Enhanced Data Rate ACL 2 Mbps mode
          Enhanced Data Rate ACL 3 Mbps mode

I do not need to change MTU size, I would just like to know EDR features
capabilities. Cannot be those information exported somehow from kernel?
I guess that kernel should have these information if it can send it to
btmon.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Determinate EDR speed

[Luiz Augusto von Dentz]

Hi Pali,

On Sun, Oct 13, 2019 at 12:39 PM Pali Rohár <pali.rohar@gmail.com> wrote:
>
> On Sunday 13 October 2019 11:45:58 Luiz Augusto von Dentz wrote:
> > Hi Pali,
> >
> > On Sun, Oct 13, 2019 at 10:36 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > >
> > > On Saturday 12 October 2019 10:23:58 Luiz Augusto von Dentz wrote:
> > > > Hi Pali,
> > > >
> > > > On Fri, Oct 11, 2019 at 11:07 PM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > >
> > > > > On Friday 11 October 2019 19:05:56 Gix, Brian wrote:
> > > > > > On Fri, 2019-10-11 at 19:00 +0000, Gix, Brian wrote:
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > On Fri, 2019-10-11 at 20:35 +0200, Pali Rohár wrote:
> > > > > > > > Currently bluez API, method Acquire() already inform called application
> > > > > > > > what is socket MTU for input and output. So from this information it is
> > > > > > > > possible to detect if device supports EDR 3 or not.
> > > > > > > >
> > > > > > > > But it is too late to have this information. I need to send SBC
> > > > > > > > parameters to bluez first when doing A2DP negotiation, this is early
> > > > > > > > steps before Acquire() is called.
> > > > > > >
> > > > > > > This seems to be the kind of information which is fixed, for the life of the pairing.
> > > > > > >
> > > > > > > What if you assumed the lower speed the first time you connected, determined the
> > > > > > > speed during the first streaming, and then either immediately renegotiate (caching the identifying
> > > > > > > information
> > > > > > > of the SNK), or just cache the information for future connections.
> > > > > > >
> > > > > > > Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> > > > > > >
> > > > > > > In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> > > > > > > documentation.
> > > > > >
> > > > > > Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> > > > > > your connection time perhaps, but would be less noticable to the user.
> > > > >
> > > > > This increase connection time, increase complexity of implementation
> > > > > (lot of things can fail) and just complicate lot of things there. Plus
> > > > > adds that glitch which is not user friendly.
> > > > >
> > > > > Also bluetooth devices, like headsets, probably do not expects that
> > > > > somebody is going to do such thing and we can hit other implementation
> > > > > problems...
> > > > >
> > > > > And moreover it is just big hack and workaround for that problem. Not a
> > > > > reasonable solution.
> > > > >
> > > > > In btmon I can see it, so kernel already knows that information. Why it
> > > > > cannot tell it to userspace and bluetooth daemon to client application?
> > > > >
> > > > > Client application (e.g. pulseaudio) should really know if is going to
> > > > > talk with bluetooth device with EDR 2 or EDR 3.
> > > > >
> > > > > > >
> > > > > > > > Therefore I'm asking for some way how to get information if device
> > > > > > > > supports EDR 2 or EDR 3. This is basically requirement for proper
> > > > > > > > implementation of SBC in high quality mode. So if there are not such API
> > > > > > > > yet, could it be exported from kernel to userspace and bluetoothd
> > > > > > > > daemon?
> > > > > > > >
> > > > > > > > See these two articles for more details about SBC and its high quality:
> > > > > > > >
> > > > > > > > https://habr.com/en/post/456182/
> > > > > > > > http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> > > > > > > >
> > > > > > > > > > Is there any bluez API for it?
> > > > > > > > > >
> > > >
> > > > There quite a few assumption here that are not really how it is
> > > > implemented in BlueZ:
> > > >
> > > > 1. The L2CAP MTU is not based on the ACL link (should be relatively
> > > > easy to change)
> > > > 2. L2CAP MTU is not required to be symmetric.
> > > > 3. Since the ACL link is shared for all channels we shouldn't really
> > > > assume all throughput will be available
> > > > 4. PA flow control is not just filling up packets and sending them
> > > > when they are full to maximize speed, instead it send packets when
> > > > necessary to maintain a constant speed so the MTU may not be fully
> > > > used, in fact trying to maximize the MTU may result in higher latency
> > > > since packets would be sent less frequently.
> > > >
> > > > With this in mind I think the only thing we should look into is to
> > > > adjust the default L2CAP MTU to match the underline ACL Link, so it
> > > > maximizes throughput, the remote side may choose a different MTU which
> > > > will have to follow though.
> > >
> > > Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
> > > normally for distinguish for usage of SBC XQ or not. Instead of MTU I
> > > rather need to know if device supports EDR 2 or EDR 3.
> >
> > I was trying to implement this on the kernel to match the MTU size of
> > L2CAP with ACL but the packet type current in use by the connection is
> > not exposed in the connection complete, or at least I couldn't any
> > reference to it, we could possibly expose the packet types via socket
> > option as well but changing it at runtime is probably not a good idea.
>
> Hello, when I run btmon, I see following information very early before
> creating A2DP connection:
>
> HCI Event: Read Remote Supported Features (0x0b) plen 11
>         Status: Success (0x00)
>         Handle: 35
>         Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
>           ...
>           Enhanced Data Rate ACL 2 Mbps mode
>           Enhanced Data Rate ACL 3 Mbps mode
>
> I do not need to change MTU size, I would just like to know EDR features
> capabilities. Cannot be those information exported somehow from kernel?
> I guess that kernel should have these information if it can send it to
> btmon.

That only indicates the remote supports these packet types it doesn't
mean they would be actually in use, which is perhaps the reason 53
bitpool was recommended since going forward than that limits the
packet types the link layer can use. What we could do in practice is
to expose what packet types can be used then you can check if EDR is
supported but you will got to trust the controller link layer will
prioritize the use of them over other packet types.


-- 
Luiz Augusto von Dentz

Re: Determinate EDR speed

[Marcel Holtmann]

Hi Pali,

>>>> Currently bluez API, method Acquire() already inform called application
>>>> what is socket MTU for input and output. So from this information it is
>>>> possible to detect if device supports EDR 3 or not.
>>>> 
>>>> But it is too late to have this information. I need to send SBC
>>>> parameters to bluez first when doing A2DP negotiation, this is early
>>>> steps before Acquire() is called.
>>> 
>>> This seems to be the kind of information which is fixed, for the life of the pairing.
>>> 
>>> What if you assumed the lower speed the first time you connected, determined the
>>> speed during the first streaming, and then either immediately renegotiate (caching the identifying
>>> information
>>> of the SNK), or just cache the information for future connections.
>>> 
>>> Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
>>> 
>>> In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
>>> documentation.
>> 
>> Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
>> your connection time perhaps, but would be less noticable to the user.
> 
> This increase connection time, increase complexity of implementation
> (lot of things can fail) and just complicate lot of things there. Plus
> adds that glitch which is not user friendly.
> 
> Also bluetooth devices, like headsets, probably do not expects that
> somebody is going to do such thing and we can hit other implementation
> problems...
> 
> And moreover it is just big hack and workaround for that problem. Not a
> reasonable solution.
> 
> In btmon I can see it, so kernel already knows that information. Why it
> cannot tell it to userspace and bluetooth daemon to client application?
> 
> Client application (e.g. pulseaudio) should really know if is going to
> talk with bluetooth device with EDR 2 or EDR 3.

actually the kernel doesn’t know either. We start with an allowed packet type mask and then the LC on each side will negotiate the current used packet types. These can change at any time. So if you want to know the current packet type, we would have to poll for it, but there is also no command that can do that.

The only thing that could be done is to limit the allowed packet types when creating the connection. However that again defeats the purpose since A2DP is not the only user of that ACL link.

What might be useful is to start using the flow specification and configure it on an ACL if an L2CAP socket for audio has been created.

Regards

Marcel

Re: Determinate EDR speed

[Marcel Holtmann]

Hi Pali,

>>>>>>>> Currently bluez API, method Acquire() already inform called application
>>>>>>>> what is socket MTU for input and output. So from this information it is
>>>>>>>> possible to detect if device supports EDR 3 or not.
>>>>>>>> 
>>>>>>>> But it is too late to have this information. I need to send SBC
>>>>>>>> parameters to bluez first when doing A2DP negotiation, this is early
>>>>>>>> steps before Acquire() is called.
>>>>>>> 
>>>>>>> This seems to be the kind of information which is fixed, for the life of the pairing.
>>>>>>> 
>>>>>>> What if you assumed the lower speed the first time you connected, determined the
>>>>>>> speed during the first streaming, and then either immediately renegotiate (caching the identifying
>>>>>>> information
>>>>>>> of the SNK), or just cache the information for future connections.
>>>>>>> 
>>>>>>> Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
>>>>>>> 
>>>>>>> In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
>>>>>>> documentation.
>>>>>> 
>>>>>> Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
>>>>>> your connection time perhaps, but would be less noticable to the user.
>>>>> 
>>>>> This increase connection time, increase complexity of implementation
>>>>> (lot of things can fail) and just complicate lot of things there. Plus
>>>>> adds that glitch which is not user friendly.
>>>>> 
>>>>> Also bluetooth devices, like headsets, probably do not expects that
>>>>> somebody is going to do such thing and we can hit other implementation
>>>>> problems...
>>>>> 
>>>>> And moreover it is just big hack and workaround for that problem. Not a
>>>>> reasonable solution.
>>>>> 
>>>>> In btmon I can see it, so kernel already knows that information. Why it
>>>>> cannot tell it to userspace and bluetooth daemon to client application?
>>>>> 
>>>>> Client application (e.g. pulseaudio) should really know if is going to
>>>>> talk with bluetooth device with EDR 2 or EDR 3.
>>>>> 
>>>>>>> 
>>>>>>>> Therefore I'm asking for some way how to get information if device
>>>>>>>> supports EDR 2 or EDR 3. This is basically requirement for proper
>>>>>>>> implementation of SBC in high quality mode. So if there are not such API
>>>>>>>> yet, could it be exported from kernel to userspace and bluetoothd
>>>>>>>> daemon?
>>>>>>>> 
>>>>>>>> See these two articles for more details about SBC and its high quality:
>>>>>>>> 
>>>>>>>> https://habr.com/en/post/456182/
>>>>>>>> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
>>>>>>>> 
>>>>>>>>>> Is there any bluez API for it?
>>>>>>>>>> 
>>>> 
>>>> There quite a few assumption here that are not really how it is
>>>> implemented in BlueZ:
>>>> 
>>>> 1. The L2CAP MTU is not based on the ACL link (should be relatively
>>>> easy to change)
>>>> 2. L2CAP MTU is not required to be symmetric.
>>>> 3. Since the ACL link is shared for all channels we shouldn't really
>>>> assume all throughput will be available
>>>> 4. PA flow control is not just filling up packets and sending them
>>>> when they are full to maximize speed, instead it send packets when
>>>> necessary to maintain a constant speed so the MTU may not be fully
>>>> used, in fact trying to maximize the MTU may result in higher latency
>>>> since packets would be sent less frequently.
>>>> 
>>>> With this in mind I think the only thing we should look into is to
>>>> adjust the default L2CAP MTU to match the underline ACL Link, so it
>>>> maximizes throughput, the remote side may choose a different MTU which
>>>> will have to follow though.
>>> 
>>> Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
>>> normally for distinguish for usage of SBC XQ or not. Instead of MTU I
>>> rather need to know if device supports EDR 2 or EDR 3.
>> 
>> I was trying to implement this on the kernel to match the MTU size of
>> L2CAP with ACL but the packet type current in use by the connection is
>> not exposed in the connection complete, or at least I couldn't any
>> reference to it, we could possibly expose the packet types via socket
>> option as well but changing it at runtime is probably not a good idea.
> 
> Hello, when I run btmon, I see following information very early before
> creating A2DP connection:
> 
> HCI Event: Read Remote Supported Features (0x0b) plen 11
>        Status: Success (0x00)
>        Handle: 35
>        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
>          ...
>          Enhanced Data Rate ACL 2 Mbps mode
>          Enhanced Data Rate ACL 3 Mbps mode
> 
> I do not need to change MTU size, I would just like to know EDR features
> capabilities. Cannot be those information exported somehow from kernel?
> I guess that kernel should have these information if it can send it to
> btmon.

so I have not seen a single device that only supports one of these two modes. They all support both and if possible you want to use 3 Mpbs anyway since that safes power.

Regards

Marcel

Re: Determinate EDR speed

[Pali Rohár]

[-- Attachment #1: Type: text/plain, Size: 5651 bytes --]

On Wednesday 16 October 2019 21:06:41 Marcel Holtmann wrote:
> Hi Pali,
> 
> >>>>>>>> Currently bluez API, method Acquire() already inform called application
> >>>>>>>> what is socket MTU for input and output. So from this information it is
> >>>>>>>> possible to detect if device supports EDR 3 or not.
> >>>>>>>> 
> >>>>>>>> But it is too late to have this information. I need to send SBC
> >>>>>>>> parameters to bluez first when doing A2DP negotiation, this is early
> >>>>>>>> steps before Acquire() is called.
> >>>>>>> 
> >>>>>>> This seems to be the kind of information which is fixed, for the life of the pairing.
> >>>>>>> 
> >>>>>>> What if you assumed the lower speed the first time you connected, determined the
> >>>>>>> speed during the first streaming, and then either immediately renegotiate (caching the identifying
> >>>>>>> information
> >>>>>>> of the SNK), or just cache the information for future connections.
> >>>>>>> 
> >>>>>>> Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
> >>>>>>> 
> >>>>>>> In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
> >>>>>>> documentation.
> >>>>>> 
> >>>>>> Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
> >>>>>> your connection time perhaps, but would be less noticable to the user.
> >>>>> 
> >>>>> This increase connection time, increase complexity of implementation
> >>>>> (lot of things can fail) and just complicate lot of things there. Plus
> >>>>> adds that glitch which is not user friendly.
> >>>>> 
> >>>>> Also bluetooth devices, like headsets, probably do not expects that
> >>>>> somebody is going to do such thing and we can hit other implementation
> >>>>> problems...
> >>>>> 
> >>>>> And moreover it is just big hack and workaround for that problem. Not a
> >>>>> reasonable solution.
> >>>>> 
> >>>>> In btmon I can see it, so kernel already knows that information. Why it
> >>>>> cannot tell it to userspace and bluetooth daemon to client application?
> >>>>> 
> >>>>> Client application (e.g. pulseaudio) should really know if is going to
> >>>>> talk with bluetooth device with EDR 2 or EDR 3.
> >>>>> 
> >>>>>>> 
> >>>>>>>> Therefore I'm asking for some way how to get information if device
> >>>>>>>> supports EDR 2 or EDR 3. This is basically requirement for proper
> >>>>>>>> implementation of SBC in high quality mode. So if there are not such API
> >>>>>>>> yet, could it be exported from kernel to userspace and bluetoothd
> >>>>>>>> daemon?
> >>>>>>>> 
> >>>>>>>> See these two articles for more details about SBC and its high quality:
> >>>>>>>> 
> >>>>>>>> https://habr.com/en/post/456182/
> >>>>>>>> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
> >>>>>>>> 
> >>>>>>>>>> Is there any bluez API for it?
> >>>>>>>>>> 
> >>>> 
> >>>> There quite a few assumption here that are not really how it is
> >>>> implemented in BlueZ:
> >>>> 
> >>>> 1. The L2CAP MTU is not based on the ACL link (should be relatively
> >>>> easy to change)
> >>>> 2. L2CAP MTU is not required to be symmetric.
> >>>> 3. Since the ACL link is shared for all channels we shouldn't really
> >>>> assume all throughput will be available
> >>>> 4. PA flow control is not just filling up packets and sending them
> >>>> when they are full to maximize speed, instead it send packets when
> >>>> necessary to maintain a constant speed so the MTU may not be fully
> >>>> used, in fact trying to maximize the MTU may result in higher latency
> >>>> since packets would be sent less frequently.
> >>>> 
> >>>> With this in mind I think the only thing we should look into is to
> >>>> adjust the default L2CAP MTU to match the underline ACL Link, so it
> >>>> maximizes throughput, the remote side may choose a different MTU which
> >>>> will have to follow though.
> >>> 
> >>> Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
> >>> normally for distinguish for usage of SBC XQ or not. Instead of MTU I
> >>> rather need to know if device supports EDR 2 or EDR 3.
> >> 
> >> I was trying to implement this on the kernel to match the MTU size of
> >> L2CAP with ACL but the packet type current in use by the connection is
> >> not exposed in the connection complete, or at least I couldn't any
> >> reference to it, we could possibly expose the packet types via socket
> >> option as well but changing it at runtime is probably not a good idea.
> > 
> > Hello, when I run btmon, I see following information very early before
> > creating A2DP connection:
> > 
> > HCI Event: Read Remote Supported Features (0x0b) plen 11
> >        Status: Success (0x00)
> >        Handle: 35
> >        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
> >          ...
> >          Enhanced Data Rate ACL 2 Mbps mode
> >          Enhanced Data Rate ACL 3 Mbps mode
> > 
> > I do not need to change MTU size, I would just like to know EDR features
> > capabilities. Cannot be those information exported somehow from kernel?
> > I guess that kernel should have these information if it can send it to
> > btmon.
> 
> so I have not seen a single device that only supports one of these two modes. They all support both and if possible you want to use 3 Mpbs anyway since that safes power.

Hi! But there are devices which support none of the two modes?

Anyway, could be these "features" exported as dbus property from bluez?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Determinate EDR speed

[Marcel Holtmann]

Hi Pali,

>>>>>>>>>> Currently bluez API, method Acquire() already inform called application
>>>>>>>>>> what is socket MTU for input and output. So from this information it is
>>>>>>>>>> possible to detect if device supports EDR 3 or not.
>>>>>>>>>> 
>>>>>>>>>> But it is too late to have this information. I need to send SBC
>>>>>>>>>> parameters to bluez first when doing A2DP negotiation, this is early
>>>>>>>>>> steps before Acquire() is called.
>>>>>>>>> 
>>>>>>>>> This seems to be the kind of information which is fixed, for the life of the pairing.
>>>>>>>>> 
>>>>>>>>> What if you assumed the lower speed the first time you connected, determined the
>>>>>>>>> speed during the first streaming, and then either immediately renegotiate (caching the identifying
>>>>>>>>> information
>>>>>>>>> of the SNK), or just cache the information for future connections.
>>>>>>>>> 
>>>>>>>>> Or the reverse, and assume fast, but immediately adjust down if you aren't getting what you hoped for.
>>>>>>>>> 
>>>>>>>>> In any case, this would be a "Device Setup" glitch which you could note as a routine part of pairing in the
>>>>>>>>> documentation.
>>>>>>>> 
>>>>>>>> Or, Stream "Silence" the first time you connect, in order to determine throughput.  It would add 1-2 seconds to
>>>>>>>> your connection time perhaps, but would be less noticable to the user.
>>>>>>> 
>>>>>>> This increase connection time, increase complexity of implementation
>>>>>>> (lot of things can fail) and just complicate lot of things there. Plus
>>>>>>> adds that glitch which is not user friendly.
>>>>>>> 
>>>>>>> Also bluetooth devices, like headsets, probably do not expects that
>>>>>>> somebody is going to do such thing and we can hit other implementation
>>>>>>> problems...
>>>>>>> 
>>>>>>> And moreover it is just big hack and workaround for that problem. Not a
>>>>>>> reasonable solution.
>>>>>>> 
>>>>>>> In btmon I can see it, so kernel already knows that information. Why it
>>>>>>> cannot tell it to userspace and bluetooth daemon to client application?
>>>>>>> 
>>>>>>> Client application (e.g. pulseaudio) should really know if is going to
>>>>>>> talk with bluetooth device with EDR 2 or EDR 3.
>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Therefore I'm asking for some way how to get information if device
>>>>>>>>>> supports EDR 2 or EDR 3. This is basically requirement for proper
>>>>>>>>>> implementation of SBC in high quality mode. So if there are not such API
>>>>>>>>>> yet, could it be exported from kernel to userspace and bluetoothd
>>>>>>>>>> daemon?
>>>>>>>>>> 
>>>>>>>>>> See these two articles for more details about SBC and its high quality:
>>>>>>>>>> 
>>>>>>>>>> https://habr.com/en/post/456182/
>>>>>>>>>> http://soundexpert.org/articles/-/blogs/audio-quality-of-sbc-xq-bluetooth-audio-codec
>>>>>>>>>> 
>>>>>>>>>>>> Is there any bluez API for it?
>>>>>>>>>>>> 
>>>>>> 
>>>>>> There quite a few assumption here that are not really how it is
>>>>>> implemented in BlueZ:
>>>>>> 
>>>>>> 1. The L2CAP MTU is not based on the ACL link (should be relatively
>>>>>> easy to change)
>>>>>> 2. L2CAP MTU is not required to be symmetric.
>>>>>> 3. Since the ACL link is shared for all channels we shouldn't really
>>>>>> assume all throughput will be available
>>>>>> 4. PA flow control is not just filling up packets and sending them
>>>>>> when they are full to maximize speed, instead it send packets when
>>>>>> necessary to maintain a constant speed so the MTU may not be fully
>>>>>> used, in fact trying to maximize the MTU may result in higher latency
>>>>>> since packets would be sent less frequently.
>>>>>> 
>>>>>> With this in mind I think the only thing we should look into is to
>>>>>> adjust the default L2CAP MTU to match the underline ACL Link, so it
>>>>>> maximizes throughput, the remote side may choose a different MTU which
>>>>>> will have to follow though.
>>>>> 
>>>>> Hi Luiz! The main problem is not MTU size, as I wrote I cannot use it
>>>>> normally for distinguish for usage of SBC XQ or not. Instead of MTU I
>>>>> rather need to know if device supports EDR 2 or EDR 3.
>>>> 
>>>> I was trying to implement this on the kernel to match the MTU size of
>>>> L2CAP with ACL but the packet type current in use by the connection is
>>>> not exposed in the connection complete, or at least I couldn't any
>>>> reference to it, we could possibly expose the packet types via socket
>>>> option as well but changing it at runtime is probably not a good idea.
>>> 
>>> Hello, when I run btmon, I see following information very early before
>>> creating A2DP connection:
>>> 
>>> HCI Event: Read Remote Supported Features (0x0b) plen 11
>>>       Status: Success (0x00)
>>>       Handle: 35
>>>       Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
>>>         ...
>>>         Enhanced Data Rate ACL 2 Mbps mode
>>>         Enhanced Data Rate ACL 3 Mbps mode
>>> 
>>> I do not need to change MTU size, I would just like to know EDR features
>>> capabilities. Cannot be those information exported somehow from kernel?
>>> I guess that kernel should have these information if it can send it to
>>> btmon.
>> 
>> so I have not seen a single device that only supports one of these two modes. They all support both and if possible you want to use 3 Mpbs anyway since that safes power.
> 
> Hi! But there are devices which support none of the two modes?

and these devices are super rare. Actually I think that HFP 1.7 ended up mandated EDR support.

> Anyway, could be these "features" exported as dbus property from bluez?

Not as easily as you think. We would have to do that via L2CAP socket if we wanted to do this cleanly and useful. Right now bluetoothd doesn’t know anything about the remote features. And the plain LMP features set is something that I wouldn’t expose anyway since the majority of the feature bits are really just for the LMP entities and not the host or the profiles.

Regards

Marcel