4 ms·

For anyone else who couldn't make head or tail of the linked page, there's more context at https://pipewire.org/ https://pipewire.org/ : PipeWire is a project

For anyone else who couldn't make head or tail of the linked page, there's more context at https://pipewire.org/ 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.

signa11 5y ago
for even more information, here is the lwn article: https://lwn.net/Articles/847412/ https://lwn.net/Articles/847412/
ufo 5y ago
Does anyone know if there is something particular special about release 0.3.46? Or is a normal release (once every other week)?
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 ago
  Any given application just needs to write samples to a buffer, effectively. That’s just the start of the processing graph.
- joshspankit 5y ago
  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 5y ago
    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.
    - deleted 5y ago
      [deleted]
- yellowapple 5y ago
  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.
clearlypenguin 5y ago
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.
- rektide 5y ago
  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.

signa11 5y ago

for even more information, here is the lwn article: https://lwn.net/Articles/847412/ https://lwn.net/Articles/847412/

ufo 5y ago

Does anyone know if there is something particular special about release 0.3.46? Or is a normal release (once every other week)?

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 ago
Any given application just needs to write samples to a buffer, effectively. That’s just the start of the processing graph.
joshspankit 5y ago
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 5y ago
  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.
  - deleted 5y ago
    [deleted]
yellowapple 5y ago
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.

clearlypenguin 5y ago

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.

rektide 5y ago
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.