PipeWire progress report - JACK, ALSA and PulseAudio back-ends nearly complete! The future of Linux multimedia production is already looking brighter.

please, o please, Pipewire, finally put an end to the mess we call "linux sound subsystem".

@MrClon Ha Ha Ha what? It's compatible with both PulseAudio and Jack. Meaning less pain and frustrarion switching sound servers when you want to record something versus when you just want to use your damn system. Which is exactly what's needed.



> PulseAudio back-ends

So it'll be PipeWire on top of PulseAudio on top of ALSA?

Sounds like XKCD pic about standards.

@dump_stack I think it's going to be PipeWire replacing PulseAudio and JACK servers so all applications can talk directly to it, also the ALSA-only programs that usually go through Pulse-Audio.
I'm not entirely sure though.
@falktx Might know beter.

@unfa @dump_stack pipewire sits on top of ALSA and provides pulseaudio and jack-compatible interfaces. the applications keep working exactly as they were before, except now they can talk to each other regardless of API, because pipewire is there on top managing the whole thing.

@falktx @unfa @dump_stack sounds awesome! i also hope it will have some of its own interfaces as well (for controlling volume and picking inputs/outputs and such), because pulseaudio's suuuuuck

So long term, jack and pulse audio will become obsolete, right? The jack/pulse interfaces are kind of a transition thing?
@unfa @dump_stack

@openmastering @falktx @unfa @dump_stack

i figure it totally depends how this will be done and implemented and how buggy it will be. i hope gnome will not be a dependecy etc. i'm wary of anything that's connected to red hat and gnome. pulse audio was a mess for quite a while.

i love separation (and compatibility) between jack (PRO!) and ALSA (average user). on the other hand it would be great if everything would *just work* low latency and talking to each other blahblah. so, i cheer for this!

@openmastering @unfa @dump_stack not sure.. pipewire devs recommend using the same (pulse/jack) APIs we do right now. I guess because not everyone is going to have pipewire installed, but they are going to have pulseaudio and/or jack.
But from a developer's perspective, JACK API is very simple yet allows to do a lot, so I do not see enough of a reason to directly use pipewire APIs since the custom pipewire libjack is staying with us for the long-term.

So pipewire would just be a kind of glorified bridge between end user protocols (jack & Pulse audio)?
I really hope that it transforms into a unified thing where users can have it all: low latency, patching, video, levels etc. Adding a complexity layer just in order to bridge services is questionable.
@unfa @dump_stack

@openmastering @unfa @dump_stack hmm well, yes, and yes and yes. have you seen the pipewire post? the screenshot already shows that in action (audio-wise). You can see Chrome in Carla's canvas (running in JACK mode), so we can already take its audio and pass through anything else in the graph.

@unfa I saw that PipeWire packages are already on Manjaro Stable repos, is this already working??

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!