Edit: there's also a patch for PulseAudio:
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)
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 , but I hope it will come out of the box soon.
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).
I really love my airpods but they stay tied to the phone now and I use a wired headset on windows for voice conferencing.
From what I read through issues and discussions basically there aren't any people to work on Bluetooth code.
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.
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
I wrote it up: https://tacosteemers.com/articles/2020-10-03-using-bluetooth...
sudo nano /lib/systemd/system/bluetooth.service
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.
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.
Project management issues like that is the one area where open source continues to struggle.
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.
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...
You might have more luck with LDAC (and LDAC enabled headsets) like Sony's wh1000xm3
You want mSBC support on HFP. Here's an open ticket for pulseaudio, for example: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge...
tsched=no fixed_latency_range=yes fragments=1 fragment_size=15
I'd also love to have high fidelity Bluetooth headset + microphone support. That 8 kHz disaster is a constant annoyance.
Their answer was finding a device that ran "aptX Low Latency" (40mS)
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.
I run Fedora, so maybe I've been picking up new versions of things like PulseAudio.
Beats having to compile it from source which is what I was doing.
I'm just happy when discord and pulesaudio behave with my wired headset.
This definitely is the best thing I read on HN all week! :)
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.