Live data from Hacker News

The Linux audio stack demystified (and more)

blog.rtrace.io

51–60 of 136 posts

Re: The Linux audio stack demystified (and more)

#51

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.

That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.

Re: The Linux audio stack demystified (and more)

#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.

Re: The Linux audio stack demystified (and more)

#53

Here's my background 1. I have to modify my audio settings every time I start a call in Teams on Linux because it keeps losing my audio device. 2. In my audio settings UI, half the time I switch my devices the speaker test doesn't work. 3. In my audio settings UI, whenever I switch my mic I hear myself. The mic feedback only disappears 30 seconds after I close the settings UI. 4. My work headsets have a robotic sound…

1. Is a known Problem with Teams

Yeah, teams definitely shares in the blame there. That one hurts more and I blame both microsoft and linux.

Re: The Linux audio stack demystified (and more)

#54
post #51

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.

That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.

Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case.

And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.

Re: The Linux audio stack demystified (and more)

#55
post #54
post #51

Earlier quoted context omitted.

That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.

Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.

And then there is Pipewire with PulseAudio plugin, and not to mention you can compile Pipewire with support for GStreamer, Jack, etc. I guess we can remove only the Arts and ESD daemons from that list, but the mess just adds up.

Re: The Linux audio stack demystified (and more)

#56
An issue I've experienced very often is that sometimes when my laptops goes to sleep and I wake it up, the speakers occasionally aren't switched to unless I restart pipewire. Same thing for headphones, sometimes when I plug them in, they aren't switched to unless I replug it in a couple of times. Might be hardware related but situations like this make me feel like I should just use linux for servers instead of for a personal computer.

Re: The Linux audio stack demystified (and more)

#57
post #54
post #51

Earlier quoted context omitted.

That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.

Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.

Aren't most of the libs you mentioned cross-platform or with a very specific use in mind which have direct analogues in Windows world?

Re: The Linux audio stack demystified (and more)

#58
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…

For me it's been nothing but problems. The primary reason is I'm probably doing things that (almost) nobody else is doing but I assume both countless people are and it should be working fine. Once I hook up some midi devices, want things to be recorded, run a synthesizer stack through pw-jack, expect the midi clock to go down the USB bus, etc, all kinds of interesting behavior starts happening. It even completely loc…

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 of midi devices with pw-jack. (I'm aware pw-jack is not required anymore, but that was my old workflow, and it speaks to the backwards-compatibility that the stack offers.)

Re: The Linux audio stack demystified (and more)

#59
post #54
post #51

Earlier quoted context omitted.

That's about maximum mess historically but thankfully most stuff on that diagram is no longer present in a modern install. And that's before pipewire which has further unified the stack.

Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.

My understanding is that pipewire finally unifies JACK and Pulseaudio. You no longer have to decide if you want a general audio setup or a low-latency one, there's a single audio server now that does everything well.

So from that list the unification is now:

- JACK and Pulseaudio are both replaced by pipewire

- OSS is long gone, ALSA is now the only low-level interface

- ESD, NAS, ClanLib, xine, portaudio, allegro and Phonon are not present in the Ubuntu install I just checked

Basically we're down to a unified stack that has BlueZ and ALSA to access actual hardware and pipewire as the single audio (and video) daemon. Everything else is either shims so apps don't need to change interface or cross platform APIs like SDL and OpenAL. We are much better than what this diagram shows.

Re: The Linux audio stack demystified (and more)

#60
post #57
post #54

Earlier quoted context omitted.

Pipewire hasn't really unified anything, it's just pw -> alsa -> hardware instead of pa -> alsa -> hardware for the common case. And not much has fallen out of use. OpenAL, libao, jack, portaudio, libcanberra, Gstreamer and phonon at least are still used widely, and a bunch of others keep cropping up occasionally in cross-platform software.

Aren't most of the libs you mentioned cross-platform or with a very specific use in mind which have direct analogues in Windows world?

Correct. You can draw just as messy a diagram for Windows. DirectSound versus OpenAL versus gstreamer(win32) versus jack(win32) versus XAudio2 versus DirectShow versus DirectMusic versus WDM Audio versus WASAPI versus UAA versus …

If there's any difference it's that under Windows, the only debugging and error handling you have is "lol reinstall all drivers and codecs and pray".

Post reply on HN