Pipewire was started by Wim Taymans, one of the gstreamer people. Originally it was supposed to allow video-streams in sandboxed environments like flatpak (and was known as "pulsevideo"), but then he noticed that it could be extended to do audio as well.
Since pulseaudio's architecture isn't well-suited to incorporate sandboxing, that project continued and it turned out that it could handle compatibility with both pulseaudio (the sound server for "consumerist" needs) and jack (the one for "pro audio" people where low latency is paramount).
You can even use programs like QJackCtl, which was written for Jack, to perform audio routing and stuff with pipewire!
So now, we have a sound server that
1. is much nicer to configure than pulseaudio
2. is compatible with sandboxing
3. is compatible with pulseaudio, jack and the older alsa
APIs and features
4. is developed much more quickly than either of the others
5. Pipewire doesn't use buffer rewinding, which was a rich source of complexity and bugs not only in PulseAudio, but also exposed bugs in the kernel audio device drivers. And even bugs or poorly specified behavior in HW itself, considering AFAIU neither macOS, Windows (nor Jack) use rewinding.
The PA docs claim that buffer rewinding is used to achieve low-latency updates to a high-latency stream. E.g., user wants to change volume now on some music that has a 2 second buffer. Seems like a common use case.
How does Pipewire deal with this?
Also-- links to the audio driver bug reports, please!
Also-- links to info on the hardware bugs, please!
It doesn't, it sets a much shorter max buffer length so that the latency is always acceptable. This does mean that in theory, with an otherwise totally idle system, PipeWire can't be quite as low power as PA.
So if Windows/MacOS/Jack all lack support for buffer rewinding without noticeable latency, does that imply that Pulse encourages the use of abnormally large buffers compared to what all other audio systems use?
Thank you! So is pipewire a replacement/superset of gstreamer? Or is it supposed to be a higher-level component (more user facing than gstreamer). Alternatively, is Pipewire about connecting audio devices (instruments, speakers) to software on the computer?
> So is pipewire a replacement/superset of gstreamer?
It is neither. Gstreamer deals with codecs and such. It's a set of libraries that an application uses to handle multimedia needs.
Pipewire is a service that handles streams and passes them off to hardware.
If you wrote e.g. a music player, you could tell gstreamer to play a .mp3 file, and it would decode it (by using its mp3 codec) and send the audio off to the pipewire socket, and pipewire would send it to the hardware to actually, you know, play. Pipewire would handle buffering and resampling and mixing and all that fun stuff.
Pipewire sits at the same level in the stack where pulseaudio sat before, and gstreamer also talked to that (and in fact you can speak to pipewire as if it was pulseaudio).
It's simply that it was written by a person also involved with gstreamer.
Since pulseaudio's architecture isn't well-suited to incorporate sandboxing, that project continued and it turned out that it could handle compatibility with both pulseaudio (the sound server for "consumerist" needs) and jack (the one for "pro audio" people where low latency is paramount).
You can even use programs like QJackCtl, which was written for Jack, to perform audio routing and stuff with pipewire!
So now, we have a sound server that
1. is much nicer to configure than pulseaudio
2. is compatible with sandboxing
3. is compatible with pulseaudio, jack and the older alsa APIs and features
4. is developed much more quickly than either of the others
See also https://fedoraproject.org/wiki/Changes/DefaultPipeWire