How is it after so many years #Linux still manages to totally fuck up the most basic and common use of #Bluetooth (audio)?
Every Bluetooth device I own connects to my Android phone without a hiccup. Every Bluetooth device I've tried (a subset of the first group) works without a hitch on the Windows machine at work.
But my main Linux box at home? About half of them don't work.
It should be a fucking embarrassment, but it seems the F/OSS crowd doesn't "grok" shame.
#Bluetooth is a fiendishly complicated protocol. I've used it on-and-off since about 2008 or so. #Android uses a completely different stack to desktop Linux. Things may be better on Windows, but there were as many as 3 different BT stacks for Windows (Toshiba, Widcomm, Microsoft).
Early attempts used an #ALSA kernel driver for Bluetooth… worked, but 8kHz mono is not the way I like to listen to music. And I'd imagine, unless your choice of music is 1930s swing, probably not yours either.
BlueZ (the standard Bluetooth stack on most Linux systems) pivoted across to doing it in user-space using PulseAudio. That worked okay for A2DP one-way audio, but for full-duplex audio, it is limiting. Notably, I found I couldn't get mSBC CODEC working, so full-duplex audio was 8kHz not 16kHz.
Most of the effort is going into linking #BlueZ and #pipewire, which I think will be the #PulseAudio successor (and may also displace #JACK.. as it has features of both systems).
Pipewire was written to do video actually (webcams), but then evolved to do audio too out of necessity. It's experimental, but I find works more reliably with Bluetooth. (And plays nicer with sound cards than JACK.)
@stuartl OK, just as a preamble, the fact you have to ask this question is part of WHY the Linux Desktop UX is such an embarrassment against literally all other alternatives. This isn't a reflection on you, incidentally, nor a commentary on your kind assistance offer. Just a data point in why the Year of the Linux Desktop hasn't happened (and likely won't happen ever).
I'm using BlueZ, I suspect, given the survey of daemons running on my system.
@stuartl Windows XP's horrendous Bluetooth situation was why I'd dismissed Bluetooth as useless for anything except mobile phone headsets for years, actually. 🤣
@qqmrichter Yeah… I don't know why the Android Bluetooth stack never got ported to standard Linux.
I would say there were technical or legal reasons why that didn't happen… maybe it was too Android-centric to make porting practical, or there was some licensing issue.
Apple from what I hear has very good Bluetooth support. I do have a MacBook here (2008-era), but haven't really done much with BT on it to find out for myself though.
You are right that, ideally, a user shouldn't need to know or care what audio or Bluetooth subsystem is running their computer. I think as PipeWire becomes more common and better integrated, displacing PulseAudio, things will improve.
I've got a Behringer BB 560M and a no-name behind-head headset that both connect without issues, operating in mSBC mode for wideband audio. I also have a no-name motorcycle headset (that I adapted to take a standard computer headset), and it works for A2DP, but HSP mode only supports narrow-band audio.
Biggest challenge is that I must manually switch between A2DP (uni-directional stereo) and HSP (bi-directional mono) profiles. Perhaps Microsoft and Apple have polished this to make it automatic, BlueZ hasn't gotten that far yet… but glass half full, both modes do at least work here.
I have one stereo headset, for example, that when I turn it on pairs with my Linux desktop, gets flagged as connected, shown as connected, shows data moving even, with the various monitoring tools, even announces in-ear "connected" (showy piece of stuff that some headsets do) ... but no sounds come out of it.
Until I disconnect it on the Linux side. Then reconnect it on the Linux side.
@stuartl Yet when I inspect everything before and after there's no visible difference. It's not like it's in one mode and switches to another when I do that. It's in the same mode in both cases. But always needs to connect on power-up, then be manually disconnected and reconnected, then it works.
This same headset works without a hitch on Android and Windows 10.
And I've got a dozen stories like this ranging from "doesn't work at all" to "bizarre as all hell" like that headset.
The only thing I can think of right now, is whether the headset is "selected" as an audio output when it first connects.
PulseAudio Volume Control (pavucontrol or pavucontrol-qt; both of these work with pipewire too) might need to be told to switch applications to that audio "sink". So it's connected, but for whatever reason, isn't chosen as being a default device.
It does sound like you're hitting an edge case… and it'd be worth capturing as much detail as you can and submitting a bug report to the particular distribution you're using.
@stuartl@qqmrichter I don't get the tone towards free/libre software devs - they don't get to choose the standards corporates present to users as a fait accompli.
Bluetooth and its Linux stack seems bad enough that a distro (Hyperbola) announced they have ripped it out - millions of lines of code, apparently.
BTW, Hyperbola sounds very off-beat. They don't want PHP or Rust or Chromium, they even want to rebuild on top of the OpenBSD kernel.
@tetrislife@stuartl They do get to decide, however, when their software is feature/code complete.
And since my starting with Linux in 2004 there are several subsystems that have always been horrific problems.
First it was video; every update had a sizable risk of breaking video. Then it was audio. Every time I saw a kernel update in my queue I groaned because I knew that I had about a 75% chance of having to mess sound until I got it working again.
Sound used to be an utter pain in the arse to get going on DOS/Windows.
You had to have the correct lines in CONFIG.SYS and AUTOEXEC.BAT for DOS games to find the sound card.
… and the multimedia extensions for Windows 3.1 were equally a fragile mess!
Apple may have had sound and video working from day dot with the Macintosh, but a bad stack of MacOS extensions could ruin your day. I also remember SimCity insisting on 16-colour mode (and its map editor: 1-bit monochrome) to work: it couldn't handle 24-bit colour.
That was a platform that was supposed to "just work".
I agree the non-technical would see this mess and run away screaming. However, many of these people would never have had a computer historically.
@stuartl@tetrislife DOS/Windows being the norm was a third of a century ago. Linux's audio problems are as little as a decade ago ... and had the entire history of Apple (starting from Apple II onward) and the PC (starting from PC-DOS onward) to learn both from their mistakes and their successes.
And learned nothing. PulseAudio finally kinda/sorta works most times but that's a recent innovation.
There is no F/OSS desktop that's user-ready yet; and likely there never will be one.
Depends on your definition of "user"… and evidently your definition of "never".
Microsoft did make great strides in the earlier part of this century, before they decided to take a wrecking ball with the combined efforts of the "Metro^WModern" UI, their "cloud first" push and most recently, their fascination with AI.
Apple's platform is good, but it requires buying their hardware (and its limited range of form-factors): go have a look at how Amazon do MacOS X instances to see where that's a problem. (spoiler: they've hacked off-the-shelf Mac Minis into 2U racks.)
You needed some functional knowledge of BASIC to do anything with an Apple computer years ago. Today, Microsoft and the KDE project are riffing off each-other UI-wise.
As for Linux audio… when I started out, Open Sound System was the standard. Most applications dealt with audio directly, there was this new fangled daemon called the e-Sound-Daemon (esd) which came from the Enlightenment desktop (and often ran along side Gnome v1).
KDE had their own called aRTS. Basically only KDE applications supported it.
ALSA got merged into the kernel with Linux 2.6. It solved a lot of problems with OSS, but still it was one application at a time. (Unless you set up dmix/dsnoop plug-ins.)
Proprietary OSS-only applications like Skype needed all sorts of unholy hacks to make it work back in the day. Everyone celebrated when they implemented ALSA support.
JACK popped up, and did allow multi-application sound-card use and flow-graph processing… but it was finicky, and better suited to advanced users.
PulseAudio is the present day, and aimed at replacing esd (and aRTS). BlueZ started working their audio infrastructure to link into that instead of ALSA.
That said, architectural issues were hit with PA, and there were ideas in JACK that were useful for solving problems, so PipeWire does a bit of both. It has support for the newer BT CODECs, and as I say, I think will ultimately replace PulseAudio.
This is almost entirely volunteers. If it took 30 years for Microsoft to get where they are today with full-time employees, it does not surprise me that the Linux community is taking a little longer. You're comparing one group who are paid a typical 40-hour week to work on their thing, to another where volunteers might only spare 10 hours a week.
I've seen printer handbooks which described the format of the commands sent down the parallel port to make a printer change fonts, colours or print graphics… but that was many moons ago! We have to reverse-engineer this in many cases today.
The only thing in favour of Open Source Software is shear numbers: there's no recruitment process to write patches or submit bug reports -- anyone can pitch in and help. (And yes, I have written a patch or two for ALSA! Probably nothing that matters in your bug.)
Sitting here moaning though isn't going to get the problem fixed. In the discussion so far, there's been no mention of distribution, kernel versions, BlueZ versions, what audio subsystem is being used (PulseAudio, PipeWire, pure ALSA, sndio…), what hardware is being used.
That doesn't give us a lot to go on. I'm not saying your problems are unimportant or non-existent… I also don't think they're unsolvable. But, we'll need detail to get to the bottom of it. 🙂
(Edit: realised Open Sound System and Open Source Software is the same acronym.)
My current problem is Bluetooth/bluez. But the overarching problem in F/OSS desktop world is that nothing quite works coherently or correctly.
For technical end-users that's an eyeroll and a groan and some research in working around the problems. For the rest that's "wow, this sucks!" and a rapid return to the familiar.
The UX in the F/OSS world is generally terrible. There's no coherence. No consistency. And no desire for it.
@qqmrichter
> the UX in the Linux world is terrible
No disagreement there, not even with fanboys overselling. Just saying, maybe devs aren't the fanboys, and the issue is systemic.
@stuartl
> we are trying to help here
Thanks, but I didn't help with the BT experience at all :-) just got involved in the parallel UX topic.
> Valve ... Linux ... Steamdeck
Very tempting if you don't want a display. Known hardware config, Linux known to work on it.
> Just saying, maybe devs aren't the fanboys, and the issue is systemic.
Oh, the issue is very MUCH systemic. It's a case of the reward cycle. As I said earlier in the thread there's no glory for making a transparent, consistent UX that gets out of the way ans enables a user to just go on and get things done. You won't get a Fossdem keynote based on "I made a Linux UX that doesn't suck". And yet UX work is some of the hardest grind you can imagine.
@stuartl@qqmrichter the current experience is just the price paid by dev mindshare going to development of a server platform - I wonder who benefited from that :-(
Devs focusing on a desktop OS of similar vintage (Haiku OS ?) ought to have helped. The Linux desktop experience suggests it isn't too late to pivot ;-)
There are so many user-oriented software artifacts insufficiently explored. Plan 9 home network? Smalltalk desktop (Squeak adopted by app devs)?
Yeah, the vast majority of Linux's history was as it being on someone's kick-around computer or as a server… HaikuOS is indeed an interesting project, been watching it from a distance for some years now.
I think the CK-sources maintainer got fed up and stopped development precisely because of the focus on server-oriented development.
Not everybody runs a server cluster in a corner of the laundry.
That said, things are changing.
Sony PS2 Linux was a flop because Sony just took their dev environment with its ancient components, and dumped the whole mess on the community.
Android has made big improvements kernel-side, but because they implement their own userland, the higher layers miss out. Hence this thread.
Recently, Valve has picked up Linux for their SteamDeck. Unlike Android, this uses freedesktop.org standards to operate. Over time, I think projects like this will help push the case for desktop Linux forward.
Windows NT 4.0 was rubbish for gaming (I know, I've been there)… Windows 2000 wasn't too bad, but things got really pushed forward when Microsoft abandoned the old DOS-based platform that was Windows 95/98/ME and made Windows XP based on NT. Now you can't play contemporary games on Windows 95/98/ME, it has to be one of the NT-based releases of Windows (unless they also support MacOS X, Linux or other OSes).
There are vendors now that will sell desktop computers and laptops running Linux today. (I'm typing this post on a StarBook VI, which came with Ubuntu originally, since loaded with Gentoo.) That wasn't a thing 15 years ago. The best we had years ago was a few obscure netbooks.
Things will change… not overnight, but they already have changed a great deal, and things are moving forward.
> typing this post on a Starbook VI
How are Starlabs as a company? They recently became available in my region, but I am balking at paying a regionally-unknown entity upfront.
They seem pretty reasonable so far… this was my first purchase from them. The machine I ordered was shipped within days, and was here the same week.
They're based on the UK, the actual product is assembled in China. Their technical support seem pretty knowledgeable, while they don't necessarily know how every distribution will run on their hardware, they are able to point out the possible trouble-spots to look out for.
As always, you often don't find out something is awry until much later.
The unit I had was ordered with Coreboot firmware, but arrived with AMI UEFI firmware -- apparently they haven't quite finished porting it over to AMD-chipset laptops yet, but allegedly will publish a guide on how to load Coreboot when the port is finished.
Add comment