* Determinate EDR speed @ 2019-10-11 8:27 Pali Rohár 2019-10-11 18:15 ` Gix, Brian 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-10-11 8:27 UTC (permalink / raw) To: linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 8:27 Determinate EDR speed Pali Rohár @ 2019-10-11 18:15 ` Gix, Brian 2019-10-11 18:35 ` Pali Rohár 0 siblings, 1 reply; 15+ messages in thread From: Gix, Brian @ 2019-10-11 18:15 UTC (permalink / raw) To: pali.rohar, linux-bluetooth 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? > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 18:15 ` Gix, Brian @ 2019-10-11 18:35 ` Pali Rohár 2019-10-11 19:00 ` Gix, Brian 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-10-11 18:35 UTC (permalink / raw) To: Gix, Brian; +Cc: ValdikSS, linux-bluetooth [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 18:35 ` Pali Rohár @ 2019-10-11 19:00 ` Gix, Brian 2019-10-11 19:05 ` Gix, Brian 0 siblings, 1 reply; 15+ messages in thread From: Gix, Brian @ 2019-10-11 19:00 UTC (permalink / raw) To: pali.rohar; +Cc: iam, linux-bluetooth 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? > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 19:00 ` Gix, Brian @ 2019-10-11 19:05 ` Gix, Brian 2019-10-11 20:04 ` Pali Rohár 0 siblings, 1 reply; 15+ messages in thread From: Gix, Brian @ 2019-10-11 19:05 UTC (permalink / raw) To: pali.rohar; +Cc: iam, linux-bluetooth 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? > > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 19:05 ` Gix, Brian @ 2019-10-11 20:04 ` Pali Rohár 2019-10-12 7:23 ` Luiz Augusto von Dentz 2019-10-16 19:05 ` Marcel Holtmann 0 siblings, 2 replies; 15+ messages in thread From: Pali Rohár @ 2019-10-11 20:04 UTC (permalink / raw) To: Gix, Brian; +Cc: iam, linux-bluetooth [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 20:04 ` Pali Rohár @ 2019-10-12 7:23 ` Luiz Augusto von Dentz 2019-10-13 7:36 ` Pali Rohár 2019-10-16 19:05 ` Marcel Holtmann 1 sibling, 1 reply; 15+ messages in thread From: Luiz Augusto von Dentz @ 2019-10-12 7:23 UTC (permalink / raw) To: Pali Rohár; +Cc: Gix, Brian, iam, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-12 7:23 ` Luiz Augusto von Dentz @ 2019-10-13 7:36 ` Pali Rohár 2019-10-13 8:45 ` Luiz Augusto von Dentz 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-10-13 7:36 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Gix, Brian, iam, linux-bluetooth [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-13 7:36 ` Pali Rohár @ 2019-10-13 8:45 ` Luiz Augusto von Dentz 2019-10-13 9:39 ` Pali Rohár 0 siblings, 1 reply; 15+ messages in thread From: Luiz Augusto von Dentz @ 2019-10-13 8:45 UTC (permalink / raw) To: Pali Rohár; +Cc: Gix, Brian, iam, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-13 8:45 ` Luiz Augusto von Dentz @ 2019-10-13 9:39 ` Pali Rohár 2019-10-13 9:49 ` Luiz Augusto von Dentz 2019-10-16 19:06 ` Marcel Holtmann 0 siblings, 2 replies; 15+ messages in thread From: Pali Rohár @ 2019-10-13 9:39 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: Gix, Brian, iam, linux-bluetooth [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-13 9:39 ` Pali Rohár @ 2019-10-13 9:49 ` Luiz Augusto von Dentz 2019-10-16 19:06 ` Marcel Holtmann 1 sibling, 0 replies; 15+ messages in thread From: Luiz Augusto von Dentz @ 2019-10-13 9:49 UTC (permalink / raw) To: Pali Rohár; +Cc: Gix, Brian, iam, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-13 9:39 ` Pali Rohár 2019-10-13 9:49 ` Luiz Augusto von Dentz @ 2019-10-16 19:06 ` Marcel Holtmann 2019-10-16 19:13 ` Pali Rohár 1 sibling, 1 reply; 15+ messages in thread From: Marcel Holtmann @ 2019-10-16 19:06 UTC (permalink / raw) To: Pali Rohár; +Cc: Luiz Augusto von Dentz, Brian Gix, iam, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-16 19:06 ` Marcel Holtmann @ 2019-10-16 19:13 ` Pali Rohár 2019-10-19 19:47 ` Marcel Holtmann 0 siblings, 1 reply; 15+ messages in thread From: Pali Rohár @ 2019-10-16 19:13 UTC (permalink / raw) To: Marcel Holtmann; +Cc: Luiz Augusto von Dentz, Brian Gix, iam, linux-bluetooth [-- 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 --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-16 19:13 ` Pali Rohár @ 2019-10-19 19:47 ` Marcel Holtmann 0 siblings, 0 replies; 15+ messages in thread From: Marcel Holtmann @ 2019-10-19 19:47 UTC (permalink / raw) To: Pali Rohár; +Cc: Luiz Augusto von Dentz, Brian Gix, iam, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Determinate EDR speed 2019-10-11 20:04 ` Pali Rohár 2019-10-12 7:23 ` Luiz Augusto von Dentz @ 2019-10-16 19:05 ` Marcel Holtmann 1 sibling, 0 replies; 15+ messages in thread From: Marcel Holtmann @ 2019-10-16 19:05 UTC (permalink / raw) To: Pali Rohár; +Cc: Brian Gix, iam, linux-bluetooth 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-10-19 19:47 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-10-11 8:27 Determinate EDR speed Pali Rohár 2019-10-11 18:15 ` Gix, Brian 2019-10-11 18:35 ` Pali Rohár 2019-10-11 19:00 ` Gix, Brian 2019-10-11 19:05 ` Gix, Brian 2019-10-11 20:04 ` Pali Rohár 2019-10-12 7:23 ` Luiz Augusto von Dentz 2019-10-13 7:36 ` Pali Rohár 2019-10-13 8:45 ` Luiz Augusto von Dentz 2019-10-13 9:39 ` Pali Rohár 2019-10-13 9:49 ` Luiz Augusto von Dentz 2019-10-16 19:06 ` Marcel Holtmann 2019-10-16 19:13 ` Pali Rohár 2019-10-19 19:47 ` Marcel Holtmann 2019-10-16 19:05 ` Marcel Holtmann
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).