HI Pali, On Sun, Jul 22, 2018 at 2:37 PM, Pali Rohár <pali.rohar at gmail.com> wrote: > On Sunday 22 July 2018 11:52:11 Georgi Boiko wrote: >> 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? > > Yes. > >> It sounds like a codec >> negotiation issue with a particular set of equipment. > > Look at mailing list discussion. This is limitation of bluez daemon. It > does not provide needed DBUS API. > > In my case, it looks like audio headset remember the last used codec. > And when I switch from phone (without aptX) to laptop (pulseaudio with > my aptX patch), then it choose SBC. > > When I disabled support for SBC at compile time in pulseaudio, headset > always choose aptX. > > This is really codec negotiation between bluez and A2DP device and we > need a way to tell bluez to switch from one codec to another. > >> 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. > > How user choose codec (config file, GUI menu, ...) is not irrelevant. > This is just second step once pulseaudio would have an option to choose > codec. Currently bluez daemon does not provide API for it. > >> > > 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. > > Yes, first you need to pair your bluetooth device and once it is paired, > then you can connect "directly". > >> 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. > > I do not know if we have an "storage" for such thing. And if not, it can > be added later and implemented. Current problem is that pulseaudio > cannot choose codec. > >> > > 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/ > > Androids are bastards and I would not rather compare anything against > them. Their decisions are bases on what Google and other vendors say, > just for marketing purposed and not how rational or technical decision > it is. > > Luiz wrote to mailing list how Android bluetooth audio is implemented > (they copy same sound buffer N times in memory) and I would expect that > this is reason why there is no aptX low-latency. You can have working > low-latency codec, but if your HAL system around is slow then such codec > is useless. And another person confirmed me that after testing Android > audio system it is fully unsuitable for anything low-latency. So this > just can prove what Luiz wrote. > >> 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. > > In any way, I do not think it overcomplicate implementation. And until > bluez does not provide needed API we are really stuck. I don't think this is true for all headset though, also perhaps you are trying to connect to a device that has already been paired? That could be an influence in this randomness, otherwise perhaps the headset is just bugged when it comes to codec selection? Also codec selection should only come into picture with user input, we shouldn't be changing codecs by policy since that will only increase the problems, so should work out the preferences when initiating the connection so if the headset plays nice and remember it then nothing has to be changed. >> Adding logic to account for re-encoding can be left for future enhancements. > > Yes. Even I have not looked at it yet. > >> 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. > > Currently I have there a new code only for aptX. There is a discussion > to separate it from bluetooth functions (for future to easily add a new > codecs). And I do it once we would know how bluez API for codec > selection would look like. > > Other codecs then can implement some else. > >> For ATRAC, I would follow the guidance here if I had to add it: >> http://soundexpert.org/news/-/blogs/audio-quality-of-bluetooth-aptx > > I have not found any headset with ATRAC support nor full encoder (for > all versions). So based on this fact I guess nobody is interested in it. > >> 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 > > Information which I have about FastStream: It is just SBC codec with > following parameters: frequency rate 44.1 kHz or 48.0 kHz, Blocks 16, > Sub-bands 8, Joint Stereo, Loudness and Bitpool = 29. So data rate = 212 > kbps, packet size = 72*3+4 = 220 = DM5 and that DSP decoders round 71 > bytes frames to 72 bytes. So I'm not sure how "low latency" it is. > Normal SBC codec allows you to specify all those parameters. But > FastStream has one additional feature: it supports backchannel for > voice, so you do not have to switch between HFP/HSP and A2DP once you > have incoming voice call. You can always use just A2DP with FastStream. > > Pulseaudio for SBC codec choose those parameters: Joint Stereo, Block > 16, Sub-bands 8, Loudness. Frequency and bitpool depends on pulseaudio > source. If bluetooth device does not support those parameters, > pulseaudio lower values. So for me it looks like that FastStream matches > default SBC pulseaudio configuration. > > Backchannel in FastStream for microphone voice again uses SBC codec with > parameters: 16 KHz frequency rate, Blocks 16, Sub-bands 8, Loudness, > Bitpool 32. So data rate = 72 kbps, packet size = 3*72 + 4 = 220 <= DM5. > Which should be much better then CVSD codec at 8 kHz used in HFP/HSP. > But is there really difference for voice data which comes from > (probably poor) microphone integrated in headsets? > >> 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. > > Based on above details I would say it must be similar (or same?) as SBC > for streaming. But who knows how is receiver implemented? I would not be > surprised if some bluetooth headset have degraded SBC A2DP codec just > for marketing purposed to show that other vendor codec is "better". > > As I said, I need to play with FastStream and see what my headset would > do with it. For me interesting part is that backchannel support to avoid > all problems with switching between A2DP and HSP/HFP profiles (to > activate HSP/HFP only in case I have incoming call and after hangup > switch back to AD2P...). > >> > > 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. >> > > > >> > > >> > > > -- > Pali Rohár > pali.rohar at gmail.com > > _______________________________________________ > pulseaudio-discuss mailing list > pulseaudio-discuss at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -- Luiz Augusto von Dentz
