On 22/07/18 10:31, Pali Rohár wrote: > On Sunday 22 July 2018 10:14:21 Georgi Boiko wrote: >> Hi Pali, >> >> Does it have to be codec switching? > > Without codec switching it is not possible to "force" specific codec. > And when bluetooth headset initiate connection, then headset choose > codec. My testing shown me that my bluetooth headset chooses codec > "randomly" when pulseaudio declares that support both SBC and aptX. > > And no, it is not a good idea to have "random" codec selection without > possibility to switch it. > > So the only possible solution for now for enforcing aptX codec is to > disable SBC codec registration to bluez. And codec registration is > global for all headset and is done when initializing pulseaudio > bluetooth module. Have you tried debugging that with hcidump? It sounds like a codec negotiation issue with a particular set of equipment. A simpler to implement alternative to codec switching via GUI could be to add a config option to enable/disable codecs when the Bluetooth module starts and negotiate using only enabled codecs. That would provide reasonable defaults with an option for power users such as yourself to force a specific codec according to their needs. This would also cut off a large chunk off the scoped changes, as no GUI-related code would have to be changed. >> If there was to be an implementation >> that settles on the best quality codec available that is supported by both >> sides of communication > > This is possible to implement, but only in the case that > pulseaudio/bluez initiate connection to bletooth headset. > > For my tested headset, this is possible only when putting headset into > bluetooth "pairing" mode. Very unpractical. In normal case, that headset > is what initialize connection. The 3 market leading Bluetooth headsets (Apple, Sony, Bose) all make the first connection through pairing mode. If you meant recurring connections, is there a way for PA to memorize which codec was used during the initial session and only supply that option later? As a user, that is what I would expect for recurring connections. >> it would already be over and beyond what currently >> exists. The order is obvious as of today: > > For me it is not such obvious as you specified. > >> LDAC >> >> AptX HD >> >> AptX >> >> AAC > > In case I have music already in MPEG/AAC then this codec should have the > higher priority as music could be passed as-is without decoding and > reencoding. In this case it is the best possible quality. Same would be > for MPEG/MP3 codec. > > Technically there are also other codecs supported by bluetooth headset, > see my research: > https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030199.html > > I have no clue right now where to put aptX Low Latency and FastStream > codecs. Plus both codecs are somehow special that misuse A2DP protocol > and optionally supports backchannel for microphone voice. So you can use > them instead of HFP for voice calls. I have there a headset with > FastStream codec and IIRC it is just some variant of SBC, so I would try > to play with it. > > And I'm still in doubt if MPEG/AAC does not provide better quality as > aptX. As long as the end result is consistent with other major platforms, you don't have to make that call. It looks like Android, for example, decided not to bother with the fine detail and with the low latency codecs, probably for the same reasons that you stated: https://android.googlesource.com/platform/packages/apps/Bluetooth/+/master/res/values/config.xml#84 + http://androidxref.com/8.0.0_r4/xref/system/bt/stack/a2dp/ I understand the desire to do it properly and to support everything with account for the fine detail, but that overcomplicates the immediate problem at hand: falling behind other platforms and being stuck with SBC. Adding logic to account for re-encoding can be left for future enhancements. It would also have a lower entry barrier on skills in C to implement than a full Bluetooth module revamp needed to get the initial support in. Given that all additional codecs are niche, I would drop them from the scope of the first milestone too. For ATRAC, I would follow the guidance here if I had to add it: http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx For codecs focusing on latency over sound quality, if I absolutely had to support them, I would put AptX LL between AptX and AAC. FastStream seems to be even more niche and focused purely on voice over HiFi audio on just a handful of Creative headsets that don't seem to support any other codecs. I would put it between SBC and AAC. If someone prefers SBC over it, they know enough about Bluetooth operation to qualify as a power user capable of using the config file to disable FastStream. >> SBC >> >> BlueZ already follows this logic, it is just that PA does not register any >> capabilities other than SBC. >> >> Allowing forced codec selection through the GUI is nice to have, but given >> the complexity of implementing it, may not be worth the hassle for the >> initial milestone. >> >> >> On 22/07/18 09:51, Pali Rohár wrote: >>> Hi! >>> >>> On Sunday 22 July 2018 00:10:47 Georgi Boiko wrote: >>>> Hi, >>>> >>>> Does anybody know what happened after this discussion? Is this long overdue >>>> upgrade on the roadmap? >>>> >>>> https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-July/028398.html >>> See this thread: >>> https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030198.html >>> >>> Basically there is a patch for aptX support, but that one just replace >>> SBC by aptX. So need to decide which codec to support at compile time. >>> >>> This is current limitation of bluez - linux bluetooth daemon - which >>> does not support codec switching. >>> >>> See also this thread: >>> https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-July/030253.html >>> >>> So until bluez is extended to support switching and configuring A2DP >>> codec, there would not be support for any other codec then SBC. >>> >> >
