Thanks for the nice writing. But do you have any insight on why is bluetooth audio so clunky on Linux? I'm using a pair of Sony XM4 and I have never had any problems on my 4 Windows machines. But on Ubuntu (both 22.04 and 24.04), I have had to jump through many hoops, from editing a bunch of config files, changing kernel flags, disable and enable a bunch of things I don't understand (mostly from reading Arch Wiki), just to get it working some of the times. Some days it will just outright refuse to connect, sometime it connects but not playing anything (switching audio device to it generates some undecipherable error logs), and (probably worst) sometime it connects very quickly but stay locked in low fidelity mode instead of a2dp sink. I'm so fed up that I just switched to wired headphones every time I use my Ubuntu.
I also have XM4's and they worked fine on Arch after addressing two problems:
Do you dual boot? Different OS's on the same computer will generate different pairing keys even though they share the same MAC, and this will cause connection issues. Usually that's reported as having to re-pair every time you switch OS's though.
I've also experienced audio skipping & popping using a dual WiFi/Bluetooth card that were eliminated by disabling WiFi. Apparently the Linux driver was faulty and allowed some interference; the card worked fine on Windows.
Thank you for linking the SE thread! So this is the reason I've been having so much trouble with my Bt devices recently. I've used Linux as my daily for years but have also started dual-booting Windows as of a few weeks ago, and I've had to re-pair every single time I'd switch systems. I just chalked it up to just generic Bluetooth issues.
Debian does not ship the AAC codec, due to legal quagmire surrounding the necessary code. The same probably goes for Ubuntu. That might be the cause of at least some of your problems. https://tookmund.com/2024/02/aac-and-debian
It's so clunky, IMO, because bluetooth is a dumbass protocol with things in the standard that should not be there (including which audio codecs are supported with which levels of bluetooth). Rather than just being a more simple network of wireless devices, it's a very complex protocol which makes everything more complicated.
Why you may struggled could be anything from the firmware blob for your bluetooth device, to the kernel driver installed, to bluez, to the sound server you are using. Any one of those things messing up will lead to a bad experience.
I've had a relatively good experience with kde-plasma's bluetooth management stuff. But I still have to do dumb things like manually selecting which audio codec to use when I go on a call.
How could bluetooth be better? It should be at least 2 standards. 1 defining the wireless data transfer and network capabilities, a second which defines how a computer negotiates with a device to send audio. It shouldn't be 2 standards merged together like it currently is. Wifi Direct is more what bluetooth should be.
> It's so clunky, IMO, because bluetooth is a dumbass protocol with things in the standard that should not be there
And yet GP has no issues on Windows...
> Why you may struggled could be anything from the firmware blob for your bluetooth device, to the kernel driver installed, to bluez, to the sound server you are using. Any one of those things messing up will lead to a bad experience.
Ah, so actually the complexity and instability of the Linux audio stack _could_ be at fault after all. But let's blame the protocol instead, even though it works fine on other operating systems.
To be fair, I agree that BT is a mess. And I've personally also had bad experiences on Windows with it. But the insanity of the Linux audio stack is indefensible. It's a major part of the problem, even if BT were a flawless and simple protocol.
How well bluetooth works depends largely on the quality of drivers from chipset manufactures. As you can imagine, manufacturers put a priority on making sure their windows systems have well functioning drivers.
You'll also notice that Android (usually) has well functioning bluetooth drivers even though it's ultimately the same linux kernel under the covers.
> Ah, so actually the complexity and instability of the Linux audio stack _could_ be at fault after all. But let's blame the protocol instead, even though it works fine on other operating systems.
The linux audio stack doesn't help things, for sure, however a lot of the complexity between the audio stack and bluetooth revolves around the fact that bluetooth requires a well implemented driver for it to work well with the audio stack.
If you compare it to something like a regular sound card you'd quickly see why that's the case. For a sound card, the driver manufactures just need a driver that can convert PCM into soundwaves. The interface is quite simple which is why you generally don't see issues with the linux audio stack and a hard wired soundcard/chip.
That's why I blame the protocol more than the stack. The protocol is very complex (needlessly so). So instead of something that could just be "send these packets to this device" you have to hope and pray that the driver you are integrating with has properly coded up various codecs needed to talk to your headphones. Instead of just throwing a bitstream at a device you are now stuck with your audio stack negotiating with the driver about which codecs to select before sending in an audio signal. This is part of what adds complexity to the audio stack in the first place.
You end up with 2 routes for the audio stack, all other sound producing and receiving devices then bluetooth.
> I'm using a pair of Sony XM4 and I have never had any problems on my 4
> Windows machines. But on Ubuntu (both 22.04 and 24.04), I have had to
> jump through many hoops [...]
I also have XM4's (best headphones in my life; seriously, they've saved
my sanity and lowered my stress levels, more than a few times), but I
never had any problems with BT pairing. I use them with my phone,
Ubuntu, OpenSUSE, ArchLinux and macOS, although not Windows, and they
always pair up perfectly fine. I have two-device mode activated at all
times.
My SO uses them (she has her own XM4's) with Windows and her phone, and
also never had any problems.
I use arch linux and have never had an issue with pairing bluetooth with anything. In fact, imho, it works much smoother than Windows because I keybind bluetoothctl to connect to any bluetooth headphones, speakers, keyboard or whatever automatically using their bluetooth device IDs. To do this you must first pair them (I use the blueman-manager gui) and then get their bluetooth device ids and keybind the bluetoothctl command. All of this is easy to do by asking ChatGPT. Hope this helps.
I've never done much with Bluetooth under desktop Linux, but that sounds like a woeful pain in the ass compared to the usual steps for Android or Windows:
1. Pair headphones in a couple of clicks/taps; sound comes out.
You can just pair as usual, yes, like any other OS, via a similar gui. And the device will then reconnect in the future.
What the parent is describing is an advanced flow, that can be helpful if you have lots of computers & need to juggle bt devices.
Setting up a hotkey just takes pre-work to setup. This workflow is optional. But it saves time & effort if for some reason you are one of the very few users who moves devices around a lot.
A hotkey is more work than GP is describing. Pairing is a one-time thing, after that they connect automatically when the headphones are on and nearby.
...which, also, is exactly what mine do with Ubuntu. I used bluetoothctl to pair them once when I first got them, and when I turn them on Ubuntu automatically connects and switches the audio over. I don't have the same model headphones as GGGP, so I'm guessing it's a problem specifically with that model's implementation (Edit: or from another person who has the same model and no issues, perhaps some combination of hardware/software specific to that user).
I think we're actually somewhat in alignment, but when you say
> Pairing is a one-time thing,
You ignore the two scenarios I face regularly, that stem from me having lots of devices and lots of computers & wanting to switch around what's paired to what.
We both seem to be trying to defeat the notion that using Bluetooth in Linux is hard or special (it's not at all, it works like anywhere else, and these reports of it being hard are from people with at best extremely small domains of experience & knowledge).
I was trying to add that Linux has further upsides for when you do want to go further, and highlight & interpret the parent post to show how I have those issues & describe how adding hotkeys (something only Linux does) would help me, an advanced user juggling many systems & device. I've clarified my post to mention that auto-reconnecting will just work on most scenarios (but I get why some folks might think it's cool to have hotkeys).
And changing it to water pistol reduces the bullying? I have seen racism expressed through colored emoticons, destroying its original intents of inclusivity. It's stupid to change it in the first place, this is just doubling the stupidity.
It's like these people didn't notice the raft of cves on hardened VPN and firewall devices lately. Cisco iOS regularly has cves. Android and iOS both have critical rces. And remember Mirai?
Well statistically Airbus is currently safer than Boeing, and as a consumer I have a choice to choose which plane to fly in, at least for my regular routes. Now you tell me why should I pick Boeing over Airbus?
The Internet is very funny. It's both incredibly reliable with insane amount of redundancy and extremely easy to screw up. A single bad BGP config can shut down the internet for a whole country ...
Cloud gaming will never be good enough for competitive FPS or racing, the latency will never be overcome, it's just physics. And if you want to do 300-400FPS, like most high-level players in CS2 do, local hardware is the only solution.
Ironically, cloud gaming is the perfect solution for single-player game, where input lag and high FPS doesn't matter much.
They can just run the same tests and cite the results from other websites. That has nothing to do with Meta. No companies can force you to not talk about them.
The tests they ran were very different from what's usually run, mostly involving perception of usefulness to humans. I don't see what website they would've cited from?
