On a side note: aptX, aptX HD and AAC are said to be superior to SBC but this is only for the default parameters that everyone is using. Bluetooth's SBC codec is very capable of producing high fidelity when using the right parameters, two channels and high bandwidth wide band, which the spec allows. There was/is a patch for LineageOS that enables SBC HD with regular phones:
This repo [1] contains all you need for getting PA to work with non-SBC codecs. I believe it ain't included cause of patent reasons but the developer of this repo is from China.
This one is so annoying thing in Linux. My Sony wireless headset works flawlessly on Windows/Mac/Android mobile without any extra installation or set up. By default the sound quality is awesome and call quality is awesome.
Now all the problems start when I want to use with Linux. By default, it uses HFP mode and you have to edit config file to make sure it faults into A2DP by default. Now headset volume is great but when I use Mic, the quality is horrible and I feel like I am living in 1900s era. There is no solution I have found to work with Linux?!
These are the things Linux will never get to the quality of Mac/Android (both are based out of *nix and they solved the problem)
I had to ask PulseAudio to use the A2DP sink only once, through the UI (either the Audio applet of Plasma, or pavucontrol, I don't remember). It's one too many, but since PulseAudio 12, A2DP should be the default [1].
As for using the microphone, I haven't tried but using the mic requires using the HSP profile unfortunately (because of the bluetooth specification). Other systems auto switch between the two profile. I think it is possible on Linux [2], but I hope it will come out of the box soon.
> This one is so annoying thing in Linux. My Sony wireless headset works flawlessly on Windows/Mac/Android mobile without any extra installation or set up. By default the sound quality is awesome and call quality is awesome.
Yep! Also an annoying one. If you accidentally click VoiceOver in the settings panel in macOS when your airpods are connected it fecks them into low quality mono mode.
I really love my airpods but they stay tied to the phone now and I use a wired headset on windows for voice conferencing.
Yeah, it's annoying. At least you can switch it, though, mine gets stuck in A2DP and the microphone won't work. Apparently all major distributions switched the Bluetooth stack to a new version even though microphone was explicitly not supported.
From what I read through issues and discussions basically there aren't any people to work on Bluetooth code.
I agree that Bluetooth audio tends to be a pain on Linux by default. However things have been flawless ever since I installed the extended pulseaudio bt codecs found here: https://github.com/EHfive/pulseaudio-modules-bt/ (pulseaudio-modules-bt on arch (AUR)). As an added bonus it now even supports LDAC!
I don't even know what you're talking about. I have a sony BT noise-cancelling headset (in fact two), and they work just fine with my Linux (pop_os) laptop. No noticeable difference with my android phone. The mike works fine, too (it's a tad low but it's not better with Android, it's this headset).
I've just checked with pavucontrol and it uses A2DP automatically by default, no configuration needed. And the microphone works with Skype and other VC programs, no configuration needed either. So well, anecdata vs anecdata.
> you have to edit config file to make sure it faults into A2DP by default
How did you do this? On my system it picks HFP by default, and tells me A2DP is unavailable until I restart PulseAudio/bluetooth - where it then picks A2DP. Happens every boot
This is why I switched to Windows and now use Linux on a VM, after more than a decade of using Ubuntu as my host OS. I couldn't have a decent Bluetooth audio experience after years of tweaking.
Something before getting into A2DP codecs is to make sure your device is using A2DP and not HFP (headset mode). Many bluetooth headphones have a microphone built in so that they can be used in headset mode, and depending on your distro and your bluetooth card, the OS may default to HFP mode. In my case, Ubuntu required me to change the Bluetooth mode every time I connected a bluetooth headphone set up until the 19.10 update.
In my case I can't even use Bluetooth microphones, just the output mode. Apparently when switching from Bluez4 to Bluez5 this was dropped by all major distributions, which frankly baffles me.
Semi related: Is headset mode worth using for voice chats? Enabling it seems to cause noise and "incoming call" voice messages. I'm not sure if it's bad support for my specific hardware type (LE Bose QC35 II) or just bad HFP support in general.
HFP mode is not worth using for anything unless you are roleplaying a person from the 90s taking a phone call in the car.
The sound quality is truly awful in HFP mode, I can hardly understand what people are saying when in that mode and you sound horrible to everyone on the other side as well.
So, is the problem because the adaptive feature of SBC is only one-way and once the bitpool is decreased (as you walk away from the transmitter and the signal degrades) it doesn't get increased again when the signal later improves? But turning it off and on again (while the signal condition is good) resets the high bitpool setting? And the workaround presented here is to basically disable the adaptive feature? If so, doesn't that then mean it'll start cutting out as you walk away, or is that that also switching to 'dual' mode prevents?
An additional problem is artificially limiting the bitpool size to 53 - which for a lot of headsets is far lower than they actually support. Since this is lossy to lossy conversion (Unless your source material is lossless of course!) - you want the second encoding step to do as little as possible - so a ridiculously high bitrate is desirable. You don't necessarily have to disable the adaptive nature of the protocol if you don't want to, but for me I get acceptable (but definitely reduced) usable range with bitpool value in the 70s. YMMV :)
Turns out I actually have the H21s. I had forgotten exactly why I wasn't using them with my XPS but turns out it's because they are a nightmare getting them to connect. Once connected the audio stutters awfully but only when I type on my wired keyboard or move my bluetooth mouse. Maybe it's my laptop at fault but it all works fine under Windows. I tried following the steps in the article (just in case that helped) but it's still unusable. Shame. I'll go back to only using the H21's them with my Android phone and in Windows, both of which work flawlessly!
I had previously read a really interesting article at https://habr.com/en/post/456182/ which vaguely talked about some limits of setting the bitpool higher and that some devices didn't support it. But seeing as I have the same MPOW headset I will give this all a try - thank you very much for sharing!
Linux is also apparently the only desktop OS that requires you to install extra configuration modules and hand-edit config files to get decent quality audio...
I'd replace "requires" with "allows". I've got lots of issues with a bluetooth soundbar on Windows which works just fine on Linux. I wish windows allowed me to hand-edit relevant config files, but it seems it's a black box.
I'm really hoping that soon I can use my mic without terrible audio. Though bluetooth is still glitchy as all get-out in Linux, and I don't know if that will ever change.
Your first link is a months-long back-and-forth between a developer who finished the HSP functionality and PulseAudio maintainers. They aren't on the same page about how to best integrate the code and seem to be very upset at each other. Is the dev being petulant? Are the maintainers being unreasonable? Hard to tell as an outsider, but there's been no progress for 5 months now.
Project management issues like that is the one area where open source continues to struggle.
Is there any alternative to SBC for two way audio? I feel like half the interviews in the media have horrible audio quality because the person on the other end is using AirPods with a handset profile.
Just curious, since it's been a while since I last used bluetooth on Linux: does BlueZ support AVDTP 1.3 delay reporting? If so, is it integrated into pulseaudio and the media stack? Windows and Android use this mechanism to delay the video by the appropriate amount to make the latency imperceptible for non-realtime content.
A HUGE issue for me is the quality during calls with a BT headset (HSP/HFP) profiles. This is a killer in my workflow as I need to be in calls all the time, and for that I need to take them through a separate windows laptop. It is crazy, I hate it. Is there a way to improve call quality?
It supports 16 kHz sampling rates and sounds decent enough, although it's still a noticeable step down from modern VoIP codecs like Opus at 12 kbit/s.
The default is 64 kbit/s PCM or CVSDM, which is limited to 8 kHz and gives you potato quality comparable to POTS phone calls.
Unfortunately, not all headsets support it (Bose and Apple Airpods consistently do, in my experience), and I have no idea if common Linux Bluetooth stacks do. This seems to be a related ticket for pulseaudio: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...
The point is that the same headset works perfectly fine on windows/android/apple devices. The call quality there is just great. Only calls on Linux are with that issue.
I'm pretty sure A2DP won't help you for calls – it's using the Bluetooth equivalent of TCP (i.e. it is connection-oriented and retransmit based), which is not appropriate for real-time communication.
Is there any plan in making it part of pulse audio shipped with Ubuntu? Is there a straight-fw way to install it somehow and enable high-quality calls for BT Headsets?
I am sure that this is a very common issue especially now-days, where people have lots of calls instead of meetings due to COVID-19...
This I'm extremely interested in trying. I am willing to bet a lot of CSR (Qualcomm) based Bluetooth hardware (a LOT of headsets seem to be based on this) probably also supports FastStream - and this would be an absolute gamechanger for me.
This was not enough for me.
In the end I replaced my bluetooth (QC35 II) headset with a non-bluetooth (HyperX Cloud S) model that had a low-latency proprietary link.
Have issues with QC35 latency as well. Definitely not buying Bose after a glacially slow support to fix bluetooth stack issues and lack of support for aptX or other low latency protocol.
I'd also love to have high fidelity Bluetooth headset + microphone support. That 8 kHz disaster is a constant annoyance.
All of the other alternatives probably work OK for non-interactive content or anything we already tolerate distance speed of light delays for (E.G. videocalls); but do so largely by delaying the video to match the audio.
SBC and LDAC (via PulseAudio) on my XM3s feel fairly decent in terms of latency; it’s probably on the order of 100ms, maybe less. I suspect Bluetooth audio latency is mostly a result of implementation details.
It's a specific design decision: The non-call audio profile (A2DP) prioritizes a low error rate over low latency by intentionally introducing a retransmit buffer on both ends of the connection.
The problem for Bluetooth non-call audio isn't (just) codec latency, but rather that A2DP is using a quite large buffer and TCP-style retransmissions. SDP itself has pretty decent latency.
SBC itself, as a codec, can have latency as low as 64 samples. But it is up to your implementation to make that happen (and bandwidth use goes up as you use smaller packets)
Bluetooth doesn't even work enough for me to use a mouse on Ubuntu 20.04. A Bluetooth speaker connected once and worked for about 2 minutes. I tried it on two different laptops, as well as with three USB bluetooth adapters of different chipsets.
Bluetooth support is all over the place for me. My Apple watch and airpods work flawlessly over bluetooth on my phone but everything else ranges from usable to very frustrating.
I've found them to be fine on Linux. It does the same 'switching' thing that it does on Windows so that when you're using the microphone you get worse audio.
I run Fedora, so maybe I've been picking up new versions of things like PulseAudio.
AFAIK I'm not sure you can make HFP sound better. Now some A2DP codecs do support a sorta backchannel to also allow mic unfortunately the support is not currently there yet in linux.
I'm running some M-Pow H12's and this is has massively upgraded the listening experience. I had noticed audio quality drop, but thought it was the capabilities of the headphone DACs/decoding processing power rather than the bluetooth encoding/decoding itself.
This definitely is the best thing I read on HN all week! :)
I feel like that codec repo is one takedown request away from disappearing. I guess there is an argument to be made for interoperability under the DMCA but we're talking about companies that want to charge a fee for every pair of headphones sold.
Why? Do you believe they have copied the code from somewhere?
The compiled binaries may be infringing on patents, but as far as I am aware source code in itself is exempt. The DMCA has nothing to do with patents though.
Weird, I was just searching for "KN100" two days ago. I didn't find much in terms of "better than a KN95 mask", but it looks like this guy's site was on Page 2.
https://www.cnx-software.com/2019/06/21/android-patch-blueto...
Edit: there's also a patch for PulseAudio:
https://lists.freedesktop.org/archives/pulseaudio-discuss/20...