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