@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
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 @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.
@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.
@falktx
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