OSS came first, then got replaced by ALSA after it became proprietary.
PulseAudio is a userspace audio server to which programs connect. It manages audio settings per app, then sends everything to ALSA. JACK is the same but with a focus on low latency.
PipeWire is a modern drop-in replacement for both, and also has support for video on Wayland.
Ohhhhhh the newbies don’t remember EsounD (Enlightenment Enlightened Sound Daemon). Basically, it was an attempt at doing PulseAudio-esque stuff way back in the OSS era. Which is to say, it just supported software mixing of multiple audio sources, because OSS usually only allowed single process to output audio. EsounD was janky and didn’t work well, obviously. Probably the neatest thing about it was that it exposed the mixed output stream to any other app, so that made visualisers much easier to make (edit: another thing that newbies in this day and age don’t realise, but I cannot emphasise enough how crucial visualisers were for the late 1990s / early 2000s music experience). ALSA basically supported hardware mixing (if available) out of the box, so of course it immediately became my favourite.
That’s not a feature thats exclusive to open source though. Circular reasoning like this just distracts from the fact that software just like hardware is constantly evolving, even in personal spaces. Thinking someone can do better has no relevance on the “open source” aspect or the political leaning.
OSS and ALSA are kernel audio drivers, they’re the most powerful of them all but extremely low level. Everything else, like pulseaudio/pipewire are just higher-level interfaces that feed ALSA audio.
There’s helvum and carla control that allow you to edit the entire audio graph with all ins and outs for all hardware and software so you can route it however you like. No need for VAC and such. But even if you do, you can load pulseaudio modules i.e. pactl load-modulemodule-null-sink and then route them with qjackctl which is absolutely crazy and awesome how pipewire lets you do that.
Give Ubuntu Studio a try maybe? It comes with a lot of audio production stuff preinstalled and preconfigured, one of the most important ones in this context being low-latency process scheduling.
Essentially most distros just have default process scheduling options, which means a process might be starved for CPU time, theoretically for up to 2s or so at a time, which is very bad if that process is generating or consuming an audio stream. Low-latency scheduling, while not entirely preventing it from happening, should significantly reduce this.
You could also just configure most other distros Kernels to do low-latency scheduling of course. Or if you don’t want to muck about with kernel settings try Ubuntu Studio, which has that and more all ready to use.
Real talk, though: why has Linux taken at least five tries (OSS, ALSA, JACK, PulseAudio, PipeWire) to get audio right?!
OSS came first, then got replaced by ALSA after it became proprietary.
PulseAudio is a userspace audio server to which programs connect. It manages audio settings per app, then sends everything to ALSA. JACK is the same but with a focus on low latency.
PipeWire is a modern drop-in replacement for both, and also has support for video on Wayland.
And then there’s also sndio, ported from OpenBSD. This does basically the same thing as OSS/ALSA.
Ohhhhhh the newbies don’t remember EsounD (
EnlightenmentEnlightened Sound Daemon). Basically, it was an attempt at doing PulseAudio-esque stuff way back in the OSS era. Which is to say, it just supported software mixing of multiple audio sources, because OSS usually only allowed single process to output audio. EsounD was janky and didn’t work well, obviously. Probably the neatest thing about it was that it exposed the mixed output stream to any other app, so that made visualisers much easier to make (edit: another thing that newbies in this day and age don’t realise, but I cannot emphasise enough how crucial visualisers were for the late 1990s / early 2000s music experience). ALSA basically supported hardware mixing (if available) out of the box, so of course it immediately became my favourite.That’s the thing about open source. Someone always thinks they can do better
That’s not a feature thats exclusive to open source though. Circular reasoning like this just distracts from the fact that software just like hardware is constantly evolving, even in personal spaces. Thinking someone can do better has no relevance on the “open source” aspect or the political leaning.
Relevant
You mean someone thinks they need to do better not by enhancement but by complete replacement. See: Systemd and its own flailing.
SystemD knows what it has to do.
everything
They don’t have the same goals.
JACK is for professional audio.
OSS and ALSA are kernel audio drivers, they’re the most powerful of them all but extremely low level. Everything else, like pulseaudio/pipewire are just higher-level interfaces that feed ALSA audio.
Pulseaudio and pipewire are sound servers.
So really it only took two tries:
OSS -> ALSA
Pulseaudio -> Pipewire
I’m still waiting for the latency to be viable for playing guitar with an audio interface.
I’m using pipewire just fine to do so? I just needed to set the buffer size to something appropriately low and I’ve had no issues from popewire’s side
Holy audio
New tip just dropped
Maybe it’s time to give it a shot again. Does pipewire have similar functionality to voicemeeter the virtual audio cables?
There’s helvum and carla control that allow you to edit the entire audio graph with all ins and outs for all hardware and software so you can route it however you like. No need for VAC and such. But even if you do, you can load pulseaudio modules i.e.
pactl load-module module-null-sinkand then route them withqjackctlwhich is absolutely crazy and awesome how pipewire lets you do that.Never used it, but I use something called pipewire graph or something (I’m on vacation and I can’t be bothered sorry heh)
Give Ubuntu Studio a try maybe? It comes with a lot of audio production stuff preinstalled and preconfigured, one of the most important ones in this context being low-latency process scheduling.
Essentially most distros just have default process scheduling options, which means a process might be starved for CPU time, theoretically for up to 2s or so at a time, which is very bad if that process is generating or consuming an audio stream. Low-latency scheduling, while not entirely preventing it from happening, should significantly reduce this.
You could also just configure most other distros Kernels to do low-latency scheduling of course. Or if you don’t want to muck about with kernel settings try Ubuntu Studio, which has that and more all ready to use.