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
