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.
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.
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 :)
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'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...
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.
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.
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.
[+] [-] ce4|5 years ago|reply
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...
[+] [-] Fnoord|5 years ago|reply
[1] https://github.com/EHfive/pulseaudio-modules-bt
[+] [-] nitinreddy88|5 years ago|reply
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)
[+] [-] jraph|5 years ago|reply
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.
[1] https://freedesktop.org/wiki/Software/PulseAudio/Documentati... [2] https://wiki.archlinux.org/index.php/Bluetooth_headset#Switc...
[+] [-] jcelerier|5 years ago|reply
eh, Macs also get their fair share of issues: https://www.jeffgeerling.com/blog/2018/airpods-get-stuck-low...
I know three different people to whom this issue has happened (not only with VMs, but with various audio software running).
[+] [-] doliveira|5 years ago|reply
From what I read through issues and discussions basically there aren't any people to work on Bluetooth code.
[+] [-] ylere|5 years ago|reply
[+] [-] wazoox|5 years ago|reply
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.
[+] [-] commotionfever|5 years ago|reply
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
[+] [-] luisehk|5 years ago|reply
[+] [-] skykooler|5 years ago|reply
[+] [-] doliveira|5 years ago|reply
[+] [-] sheenobu|5 years ago|reply
[+] [-] kingosticks|5 years ago|reply
[+] [-] kn100|5 years ago|reply
[+] [-] fomine3|5 years ago|reply
[+] [-] IshKebab|5 years ago|reply
[+] [-] mmm_grayons|5 years ago|reply
Along with adding mSBC support to HFP: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...
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.
[+] [-] dnquark|5 years ago|reply
Project management issues like that is the one area where open source continues to struggle.
[+] [-] voltagex_|5 years ago|reply
[+] [-] lxgr|5 years ago|reply
You're probably talking to someone using legacy PCM 8 kHz because either their headset or their computer/phone does not support mSBC for voice calls.
[+] [-] chenxiaolong|5 years ago|reply
[+] [-] niksakl|5 years ago|reply
[+] [-] lxgr|5 years ago|reply
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...
[+] [-] amelius|5 years ago|reply
[+] [-] dijit|5 years ago|reply
You might have more luck with LDAC (and LDAC enabled headsets) like Sony's wh1000xm3
[+] [-] vardump|5 years ago|reply
[+] [-] eggsome|5 years ago|reply
[+] [-] mjevans|5 years ago|reply
Their answer was finding a device that ran "aptX Low Latency" (40mS)
https://en.wikipedia.org/wiki/AptX#aptX_LL
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.
[+] [-] jchw|5 years ago|reply
[+] [-] lxgr|5 years ago|reply
[+] [-] dmitrygr|5 years ago|reply
[+] [-] sgtnoodle|5 years ago|reply
[+] [-] Polylactic_acid|5 years ago|reply
[+] [-] beilabs|5 years ago|reply
[+] [-] rkangel|5 years ago|reply
I run Fedora, so maybe I've been picking up new versions of things like PulseAudio.
[+] [-] lxgr|5 years ago|reply
[+] [-] pitterpatter|5 years ago|reply
[+] [-] noir_lord|5 years ago|reply
Beats having to compile it from source which is what I was doing.
[+] [-] swiley|5 years ago|reply
I'm just happy when discord and pulesaudio behave with my wired headset.
[+] [-] squarefoot|5 years ago|reply
[+] [-] bArray|5 years ago|reply
This definitely is the best thing I read on HN all week! :)
[+] [-] ikeboy|5 years ago|reply
[+] [-] voltagex_|5 years ago|reply
[+] [-] poizan42|5 years ago|reply
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.
[+] [-] p1mrx|5 years ago|reply
[+] [-] kn100|5 years ago|reply
[+] [-] amelius|5 years ago|reply