[js6i]

Never did any audio programming, I still can't make heads or tails out of it. Is it expected that an application sets up some processing graph for an engine to play a sound? [1] Instead of writing samples to a buffer in a loop? Who wants that?

[1] https://docs.pipewire.org/page_tutorial4.html

[joshspankit]

Buffers necessitate latency.

Also, while I don’t know the project yet I can see the benefit in building something from the ground-up in a way that embraces multi-process “in/out” pipes. Someone could have dozens of effects all connected to the audio signal, then run that to dozens or hundreds of outputs (streams online, multiple speakers, recording applications, analog mixer inputs...). Traditionally that kind of usage is fragile as memory corruption can happen at any stage since everything is writing/reading the same buffer. If they have a true graph implementation then applications could interact with the graph edges and the overall system would be much more robust.

[js6i]

And doesn't processing necessitate buffers? How does this approach reduce the number of buffers involved? If anything, it sounds like less sharing would mean more buffers.

[Filligree]

Any given application just needs to write samples to a buffer, effectively. That’s just the start of the processing graph.

[yellowapple]

I don't know of very many applications that use PipeWire directly (at least for audio); usually a program would target some other Linux audio API (ALSA, PulseAudio, JACK), for which PipeWire would provide the necessary plumbing and libraries to be a drop-in replacement for those older APIs.