cannedtunasystemctl status --user pipewire
Real talk, though: why has Linux taken at least five tries (OSS, ALSA, JACK, PulseAudio, PipeWire) to get audio right?!
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.
You mean someone thinks they need to do better not by enhancement but by complete replacement. See: Systemd and its own flailing.
everything
Something Burger 🍔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.
heliotropeAnd then there’s also sndio, ported from OpenBSD. This does basically the same thing as OSS/ALSA.
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
RVGamer06New 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-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.
RoseOhhhhhh the newbies don’t remember EsounD (Enlightenment 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. ALSA basically supported hardware mixing (if available) out of the box, so of course it immediately became my favourite.
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