The Audio Stack Is a Crime Scene(fireborn.mataroa.blog)
fireborn.mataroa.blog
The Audio Stack Is a Crime Scene
https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-doesnt-love-me-back-post-2-the-audio-stack-is-a-crime-scene/
18 comments
The Linux audio stack is just baffling. After all these years it's still unreliable. I'm running Fedora 41 and often toggle between two audio devices, USB DAC and HDMI output. Sometimes when I change the output via Gnome settings my Flatpak apps don't care and keep playing with the previous output and other apps change as expected.
I've never edited any audio configs on this machine because I expected my 2 device setup and Gnome settings would be trivial enough for the latest Linux desktop audio solution.
I've never edited any audio configs on this machine because I expected my 2 device setup and Gnome settings would be trivial enough for the latest Linux desktop audio solution.
the cause of all this? single client ALSA driver model.
coreaudio doesn't need pulse nor jack nor pipewire to allow a single device to be opened by multiple applications.
ALSA additionally specifies every 2 channels as separate 2channel devices, so your 8 channel audio interface looks like 4.
the confusion is added to by device tree overlays such that you may find your pro audio 8 channel device is always seen as a surround setup, replete wirh highpass filtering on the principle pair of outputs, and you don't know why your poor desktop environments sound device doesn't show this...
coreaudio doesn't need pulse nor jack nor pipewire to allow a single device to be opened by multiple applications.
ALSA additionally specifies every 2 channels as separate 2channel devices, so your 8 channel audio interface looks like 4.
the confusion is added to by device tree overlays such that you may find your pro audio 8 channel device is always seen as a surround setup, replete wirh highpass filtering on the principle pair of outputs, and you don't know why your poor desktop environments sound device doesn't show this...
> ALSA additionally specifies every 2 channels as separate 2channel devices, so your 8 channel audio interface looks like 4.
There is no such specification. It is device-dependent and abstracted through ALSA configuration. Creative Labs indeed implemented their cards as three separate codecs, while ForteMedia used a single 6-channel codec that you can open as such at the hardware level. In both cases, you can open a single virtual "surround51" device that routes the channels correctly.
There is no such specification. It is device-dependent and abstracted through ALSA configuration. Creative Labs indeed implemented their cards as three separate codecs, while ForteMedia used a single 6-channel codec that you can open as such at the hardware level. In both cases, you can open a single virtual "surround51" device that routes the channels correctly.
Windows is better but not much. My big PC at home isn't completely reliable to attach to Bluetooth headphones, some of which might be the fault of the particular headphones, but some of which seems to be the fault of having various sorts of "virtual" drivers installed such as for Steam, MQ 3, Immersed, etc.
Yeah, I always feel surprised when people call out the Linux audio experience as uniquely bad. Meanwhile on Windows I need to jam voicemeter in the middle to separate inputs and outputs so I don't have games crashing to desktop because my bluetooth headset ran out of battery, while Mac makes each individual application implement volume control UI.
Windows' Bluetooth stack is an absolute dumpster fire. They trashed the perfectly good BT stack from windows 7 and apparently had an unpaid intern write the replacement.
My day job is building widgets that connect to a windows PC over Bluetooth. The situation is so bad that we're building a dedicated RF adapter so we can have a sane stack under our control.
If your program is scanning for a particular device in the background, that device will never show up in the windows BT pairing menu. I can't even imagine how that happens. Many API calls do nothing or return garbage, many BT features are just not exposed at all, despite windows clearly having that data internally.
W10 never even had BT audio sink. You could not play audio from a remote device to your PC. W7 had it and I think W11 finally got it a few years back. Linux has always had it.
Windows' Bluetooth stack is no contest the worst available on the market. It's astonishing how poor quality Microsoft products are these days.
My day job is building widgets that connect to a windows PC over Bluetooth. The situation is so bad that we're building a dedicated RF adapter so we can have a sane stack under our control.
If your program is scanning for a particular device in the background, that device will never show up in the windows BT pairing menu. I can't even imagine how that happens. Many API calls do nothing or return garbage, many BT features are just not exposed at all, despite windows clearly having that data internally.
W10 never even had BT audio sink. You could not play audio from a remote device to your PC. W7 had it and I think W11 finally got it a few years back. Linux has always had it.
Windows' Bluetooth stack is no contest the worst available on the market. It's astonishing how poor quality Microsoft products are these days.
I'm still baffled by difference between Audacity on Windows and Linux. On Windows I have n+1 recording devices, where n is number of microphones, the 1 being stereo mix. On Linux I have gazillion cryptic names and I pray for each of them to even work. And neither of them is stereo mix, for such advanced feature I have to enable external mixer.
Stereo mix is a surprisingly neutral nontrivial feature. How do you mix the channels, are you okay with limitations of software mixer, do you want to hardware mix it on supported audio chipsets, what stereo mix means when you have three or more microphones?
A stereo mix is in fact trivial and roughly assumes a left right speaker arrangement. Software summing is math and is the same across digital audio workstations because math is math. Are there 3 or more microphones? doesnt matter, each mic is a mono input. trying to capture a facsimile of a perceived stereo field? use ORTF mic spacing and hard pan those mono inputs appropriately.
Stereo is just dual mono. its that simple. Summing is just math, its that trivial.
Creating a mix of multiple inputs for a stereo lr output? also completely trivial from a technical standpoint. Hardly trivial from a creative pov, but that isnt what this is about.
Stereo is just dual mono. its that simple. Summing is just math, its that trivial.
Creating a mix of multiple inputs for a stereo lr output? also completely trivial from a technical standpoint. Hardly trivial from a creative pov, but that isnt what this is about.
After upgrading to Intel Bluetooth/Wlan module I have had lot less issues.
But in general Bluetooth is just bad protocol audio...
But in general Bluetooth is just bad protocol audio...
Precisely the reason I don't understand how people can daily drive Linux on their laptop. (I say laptop because additionally: trackpad issues, Bluetooth issues, etc.)
Is it much better than 10 or 20 years ago? Yes.
Is it still annoying enough and sometimes colossal waste of time? Yes. Just use a Macbook and be done with it.
Is it much better than 10 or 20 years ago? Yes.
Is it still annoying enough and sometimes colossal waste of time? Yes. Just use a Macbook and be done with it.
I think it depends on what laptop.
Asus laptops have always worked flawlessly for me.
I am writing this on an Asus laptop with linux mint. Everything just works perfect out of the box.
I could buy three of these laptops instead of the same setup on a mac is the major selling point for me.
Asus laptops have always worked flawlessly for me.
I am writing this on an Asus laptop with linux mint. Everything just works perfect out of the box.
I could buy three of these laptops instead of the same setup on a mac is the major selling point for me.
> The stack is clean. The interfaces are better. But the expectations are still stuck in 2012.
The interfaces are absolutely not better, they're a bunch of ~~undocumented~~ C preprocessor macros that hide a pit of complexity and indirection. Pulse is mature enough that you can figure out how to interface with it, pipewire has a handful of examples and some reference documentation that doesn't make sense if you don't already know what you're looking for. Good luck if those examples don't fit nicely into your existing applications' architectures.
Pipewire is very impressive as an achievement, but the work needs to be put in to make it mature enough as a software project (meaning: documentation and well typed interfaces) before existing software can work with it.
The architecture may well be better equipped to provide stable and elegant interfaces to complex media routing problems in application software. But I couldn't tell you if that's true or not, because it's sparsely documented. An undiscoverable API is a nonexistent one.
edit: I wrote this ignorantly before looking back at the pipewire docs. They've improved since I last looked, but I still find the docs lacking (comparable to Apple's docs, which is not a compliment) and the overall interface design of Pipewire a massive challenge to grasp. It might be better, but I don't know. The last time I tried to implement direct support for pipewire in a Linux app I gave up because of its design and lack of useful documentation.
The interfaces are absolutely not better, they're a bunch of ~~undocumented~~ C preprocessor macros that hide a pit of complexity and indirection. Pulse is mature enough that you can figure out how to interface with it, pipewire has a handful of examples and some reference documentation that doesn't make sense if you don't already know what you're looking for. Good luck if those examples don't fit nicely into your existing applications' architectures.
Pipewire is very impressive as an achievement, but the work needs to be put in to make it mature enough as a software project (meaning: documentation and well typed interfaces) before existing software can work with it.
The architecture may well be better equipped to provide stable and elegant interfaces to complex media routing problems in application software. But I couldn't tell you if that's true or not, because it's sparsely documented. An undiscoverable API is a nonexistent one.
edit: I wrote this ignorantly before looking back at the pipewire docs. They've improved since I last looked, but I still find the docs lacking (comparable to Apple's docs, which is not a compliment) and the overall interface design of Pipewire a massive challenge to grasp. It might be better, but I don't know. The last time I tried to implement direct support for pipewire in a Linux app I gave up because of its design and lack of useful documentation.
the interfaces are shite, from the same clown who invented systemd
just use one file per stream eg /dev/dsp/pid_tempfile eg /dev/dsp/778_gJG86h, move mix to kernel, give it a /proc interface. the unix way
just use one file per stream eg /dev/dsp/pid_tempfile eg /dev/dsp/778_gJG86h, move mix to kernel, give it a /proc interface. the unix way
I got bit by linux audio issues after moving from Win10 to CachyOS (arch based distro). It seemed to be working fine, but I noticed when switching to speakers a terrible digital distortion that wasn't there previously.
(I'm not a linux noob, have used since Debian Bo in '97, for example, plus many other distros off and on through the years)
I spent so much time messing with alsamixer, removing pipewire, installing pulse, uninstalling pulse, readding pipewire, resetting ports and connections.
I realized it had something to do with the audio buffer (due to the echo and the distortion was "shaped" like the feedback/if that makes sense). like a half second delay feedback.
Ultimately I read up on the buffering mechanism and found that switching to the Bore-LTO kernel fixed everything. I was so desperate I was literally swapping ends of my cables between the PC and speaker, in theory it shouldn't matter but before realizing the issue when I noticed the noise was based on a delay/feedback, I had no other alternative and was at my wits end.
I spent so much time messing with alsamixer, removing pipewire, installing pulse, uninstalling pulse, readding pipewire, resetting ports and connections.
I realized it had something to do with the audio buffer (due to the echo and the distortion was "shaped" like the feedback/if that makes sense). like a half second delay feedback.
Ultimately I read up on the buffering mechanism and found that switching to the Bore-LTO kernel fixed everything. I was so desperate I was literally swapping ends of my cables between the PC and speaker, in theory it shouldn't matter but before realizing the issue when I noticed the noise was based on a delay/feedback, I had no other alternative and was at my wits end.
Facts. I still don't think pavucontrol, the GTK volume control tool for PulseAudio, has been replaced by a PipeWire native tool. (I have no idea what Helvum is for, and pavucontrol has minimal backing.) And since I messed with it one time now using headphones is all jacked.
Another area where FreeBSD excels.
It was a disaster. If the USB audio interface ever disconnected, JACK crashed and wiped my routing configuration. After the first day I ditched the Linux computer and ran the whole setup through my MBA, using Reaper for both recording and routing.