Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Linux audio stack demystified (and more)

blog.rtrace.io

Post reply on HN
Print view View original

71–80 of 136 posts

Re: The Linux audio stack demystified (and more)

#71

Post by lynx23 »

Well, we had a lot of layers in Linux Audio the last 30 years. But when PulseAudio was forced into the world by a c-section, with everyone in the LA community already knowing its a still-birth, I kind of lost trust in coordinated project creation. PA makes me so unhappy that I totally uninstall it whereever I see it. Good for me that I am just a console user, because the damn beast is all over the GUI space.

Fact is, RT audio is hard, and the peoplebehind JACK have cared for the underlying problems for a long time already.

Maybe PipeWire, but to be honest, it reminds me too much of PA.

I guess I will stay with plain JACK and SuperCollider as my toolbelt, and not care about PA or PW. Like the grumpy old hacker I am.

Re: The Linux audio stack demystified (and more)

#72

Post by opyate »

kristopolous wrote: post #65
opyate wrote: post #58

Earlier quoted context omitted.

It would be helpful if folks on here who say "works for me"/"doesn't work for me" would indicate which flavour/version of Linux they use. Some distros don't have the latest pipewire stack, and you're left to fend for yourself, having to follow some incomplete or poorly written blog post to side-step what your distro does and put pipewire on top. Me: Ubuntu 24.04 LTS, and happily using carla, ardour, lmms and a bunch…

Understood but I thought it was clear at least from my post that this isn't a distribution problem. I've certainly tried the distribution version, building from source, and various other things. I have a counter-request: It's really frustrating when people are like "It just works! I had no problem! It's so easy!" in response to someone who has clearly struggled to get things working. It'd be like someone telling you…

I hope you figure it out :)

I think the stars just aligned for me, and it worked. Not an expert at all on these things.

Re: The Linux audio stack demystified (and more)

#73

Post by fulafel »

JodieBenitez wrote: post #42
kmarc wrote: post #24

I hear many complaining (even here) about "the mess" of linux audio. First, in the article, [1] shows in one single diagram where the complexity is coming from; the audio system has to handle a good deal of different hardware on many different systems and also provide extra functionality for multiplexing, network features, wireless headsets and their codecs, etc. All this: open source. Second: linux is the only platf…

That's the very first time I read "sanely-working-out-of-the-box" about Linux audio. I have a very different experience of course, such as "why do my BT headphones suddenly play everything at 8000hz sampling rate while I never asked for this and why the UI won't let me switch it back to 24khz ?".

Sounds like HFP. For me on Ubuntu you can choose between audio playback profile and HFP in the sound settings ui, but maybe you have an app running that is changing that setting.

(Apologies for injecting advice into a grumbling thread)

Re: The Linux audio stack demystified (and more)

#74

Post by [deleted] »

gen2brain wrote: post #49

Whenever someone mentions Linux and Audio I always remember this image (made by Adobe I think) https://harmful.cat-v.org/software/operating-systems/linux/a... . It is missing Pipewire but it should be easy to add a dozen of new lines. This is the reason why I simply use plain ALSA without any sound daemons.

[deleted]

Re: The Linux audio stack demystified (and more)

#75

Post by miki123211 »

probablybetter wrote: post #68

The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing device…

> The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model.

This is one of the major reasons why Linux accessibility sucks IMO.

Audio is one thing that you need to "just work™" if you want to get accessibility right, as there's no way for a screen reader user to fix it without having working audio in the first place[1]. On Linux, it does not "just work", and different screen readers have different ideas on how they want audio to be handled. In particular, the terminal Speakup screen reader (with a softsynth) wants exclusive control of your device through ALSA IIRC, while the Orca screen reader for the GUI goes through Pulse. That makes it impossible to use both of them at the same time.

[1] Well, you can sort of fix it by having a second machine and SSHing into the broken one, but that's not what I mean.

Re: The Linux audio stack demystified (and more)

#76

Post by woolion »

kristopolous wrote: post #65
opyate wrote: post #58

Earlier quoted context omitted.

It would be helpful if folks on here who say "works for me"/"doesn't work for me" would indicate which flavour/version of Linux they use. Some distros don't have the latest pipewire stack, and you're left to fend for yourself, having to follow some incomplete or poorly written blog post to side-step what your distro does and put pipewire on top. Me: Ubuntu 24.04 LTS, and happily using carla, ardour, lmms and a bunch…

Understood but I thought it was clear at least from my post that this isn't a distribution problem. I've certainly tried the distribution version, building from source, and various other things. I have a counter-request: It's really frustrating when people are like "It just works! I had no problem! It's so easy!" in response to someone who has clearly struggled to get things working. It'd be like someone telling you…

Have you tried Linux audio forums/community? I think the problem is that, by experience, regular musicians will just say "you need to use windows (or mac) to do anything serious" so it's complicated to find enough people that are competent in both skills.

Re: The Linux audio stack demystified (and more)

#77

Post by probablybetter »

poakjsn wrote: post #52

Linux distros would be best off lifting as much as possible from the Android Open Source Project, i.e. a professional and streamlined Linux-based system that actually works and isn't just a mishmash of incompatible, poorly designed hobbyist trash. The year of the Linux desktop never arrived but most of the world has Linux sitting in our palms. Let's build on that instead of the dead ends of Debian, Slackware, etc.

wow. no. debian is the opposite of a dead end. now, ubuntu and lubuntu and xubuntu = i agree. android, however, is garbage. - it most certainly is not consistent across devices and editions - having to do phone-like-stuff on a desktop/laptop is painful - i hate Android. It's settings bother me the most. there is ZERO organization here! There are DARK patterns galore, it's built to dissuade you from doing anything serious.

I can only take your comment as either a joke, or you literally only use a phone/tablet in life.

news flash: Android audio is ALSA at it's core. Additionally: native Android audio is ultra-high-latency... completely unacceptable for pro-audio

Re: The Linux audio stack demystified (and more)

#78

Post by probablybetter »

Am I the only one that sees unfriendly input/output channel names with Pipewire in client software?

(Bitwig, Ardour, Reaper, more? I would like to see "Input 1" or "Channel 1" and not some strange ciphers when trying to assign things in a little dropdown selector in a DAW)

Re: The Linux audio stack demystified (and more)

#79

Post by curt15 »

poakjsn wrote: post #52

Linux distros would be best off lifting as much as possible from the Android Open Source Project, i.e. a professional and streamlined Linux-based system that actually works and isn't just a mishmash of incompatible, poorly designed hobbyist trash. The year of the Linux desktop never arrived but most of the world has Linux sitting in our palms. Let's build on that instead of the dead ends of Debian, Slackware, etc.

Hasn't Android audio always struggled with input latency?

Re: The Linux audio stack demystified (and more)

#80

Post by jcelerier »

probablybetter wrote: post #68

The "mess" of Linux audio is due to ONE reason: single-client ALSA driver model. every other layer is a coping mechanism and the plurality and divergence of the FOSS community responds in various ways: - Jack - PulseAudio - PipeWire I am unclear why Jaroslav Kyocera chose to make ALSA single-client, but Apples CoreAudio multi-client driver model is the right way to do digital audio on general-purpose computing device…

> current audio production systems have the DAW software directly opening an ALSA device.

I mean, I remember this being the case for a very long time on windows with ASIO too, which is the only reasonable way to run a DAW with acceptable latency there. MacOS has multi-client but I was never able to get latency as low as fine-tuned windows and Linux systems, and in the end that's what matters - you just use your motherboard's chip for OS audio and your pro soundcard for the actual workload. Pipewire is very close to giving a good experience but there'll always be some overhead - I'm making some art installations running various chains of audio effects on a raspberry pi zero and the difference between going through pipewire even if my app (https://ossia.io) is the only process doing any sound, and going straight to ALSA, is night and day in terms of "how many reverbs I can stupidly chain before I hear a crack".

Post reply on HN