Can anyone explain me like I'm five, why this major transition from PulseAudio to PipeWire is happening during the last year?
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
How does Pipewire deal with this?
Also-- links to the audio driver bug reports, please!
Also-- links to info on the hardware bugs, please!
I believe you, I just want to read about them.
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.
"DOC,ENH: How to connect container pipewire, alsa, jack to host pipewire (#1612)" https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/16...
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.
(Gstreamer is fantastic as a swiss army knife, but something a bit more focused is needed).
I believe this will interface with gstreamer just fine though.
Actual advantages of pipewire vs pulseaudio are not that obvious, but it should mostly be lower-latency, hopefully more stable, and more flexible (provide something like the old `jack` API where any stream can be plugged anywhere). Also, support for sandboxing (flatpak portals) is first-class, as one of the early design goals was to provide this for video.
Pipewire is also used in most places where wayland is, to provide screen sharing capabilities (now, if proprietary software could catch up... looking at zoom).
And lastly, pipewire should hopefully become one of the best APIs for accessing webcams and other video streaming devices in the future (allowing stuff like sharing a camera between multiple apps, simple sandboxing, middleware for compositing or video effects -- think background removal tools). Support is a bit sparse for now, but there's a LD_PRELOAD workaround for v4l2 interfaces.
Edit: also, pipewire gained support for nicer bluetooth codecs faster than pulseaudio did.
Yep, I have a pair of Sony WH-1000XM3 which supports better codecs like LDAC and you had to resort to a 3rd party, home-made repository in Ubuntu for pulseaudio (initially there were licensing reasons but then Sony opensourced it IIRC). With PipeWire (on Ubuntu 21.10) I just have to install a package from the standard repo.
For example, I have an electric piano that I can connect to my computer and play. I had to install a special software called "jack", because PulseAudio would have me wait before I could hear a note I played.
Jack was not simple to use, but even if you were good at it, there were problems. Imagine you wanted to play along with some music. Well, bad luck, some software do not support jack, and you can't use it together with PulseAudio.
Now lets say I want to stream my playing on Twitch. Again I will have trouble, because the many moving parts in streaming, including video, make it very difficult to output a high quality stream.
Last, when I use DaVinci Resolve to edit and upload my stream to Youtube, I want to record some voice over. Resolve has this function called "ADR", or "Automated dialogue replacement" -- it's a feature they use in film to record the actors on the computer. I could use that to record my voice over, but ADR on Resolve doesn't bother with either Pulse or Jack, and uses something called "ALSA". That means that until Resolve finishes using it, I can't use my microphone!
With Pipewire I just click and it works.
You absolutely can, PA is then present in JACK (and JACK in PA) as a single sink/source that you can route like any other app - so not as flexible as PipeWire, but not as problematic as you paint it either.
With pipewire, this works quite nicely, including for applications that are sandboxed (e.g. Jitsi in a Flatpak). In my bubble, when people talked about using Pipewire, it was almost exclusively related to screensharing on Wayland.
I've switched from Pulseaudio to Pulseaudio-on-Pipewire last year and haven't looked back. Next step would be trying to set an audio processing pipeline with audio effects (like a multiband equalizer tuned to my headphones), something that I managed to set up with Jack before using Pipewire, but that was always a pain.