Hacker News new | ask | show | jobs
by meredydd 1589 days ago
For anyone else who couldn't make head or tail of the linked page, there's more context at https://pipewire.org/ :

PipeWire is a project that aims to greatly improve handling of audio and video under Linux. It provides a low-latency, graph based processing engine on top of audio and video devices that can be used to support the use cases currently handled by both pulseaudio and JACK.

4 comments

Does anyone know if there is something particular special about release 0.3.46? Or is a normal release (once every other week)?
for even more information, here is the lwn article: https://lwn.net/Articles/847412/
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

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.

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.
Any given application just needs to write samples to a buffer, effectively. That’s just the start of the processing graph.
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.
Side note, why is posting a link to a changelog a common and accepted way to share links on HN? You are correct, reading the linked page is pointless until we understand what PipeWire is.
I love & read these changelog posts avidly. They are regular & amazing.

We should have nuanced interesting advanced tech shared here. Not everything needs to target complete newcomers.