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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
