4 ms·
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
by js6i 5y ago
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 https://docs.pipewire.org/page_tutorial4.html
- Filligree 5y agoAny given application just needs to write samples to a buffer, effectively. That’s just the start of the processing graph.
- joshspankit 5y agoBuffers 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 5y agoAnd 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.
- deleted 5y ago[deleted]
- yellowapple 5y agoI 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.