Red Hat / Fedora To Focus On Driving New Linux Video Improvements Around PipeWire

[doomie]

It was the complete opposite experience for me. After 5-15 years of pulseaudio still having bugs and weird quirks, I finally switch to pipewire, which solved them all to me. Only minor annoyances that were fixed after a few weeks after I starting using it.

It's been a tradeoff in bugs/functionality for me, but worth it, so pipewire I use :P

That latency tho...

[Charlie68]

My opinion for what it's worth ... I've been using pipewire for a few months on Tumbleweed and I have to say that I haven't had any major problems, it worked quite well, however Pulse also works well and I have not noticed any difference in use " normal". I listen to music with my desktop, connected to a stereo and both have good quality. So in the end, I am happy that Pipewire works well and perhaps for some users it is even better than Pulse, for me it is indifferent.

[Michael_S]

Pulseaudio plus Firefox always led to crackling audio for me after a few days of uptime. Running "pulsesaudio -k" would fix it for another day or two, then it was back.

I installed Pipewire a month ago, and my audio remains fine.

[alfredon996]

Too bad Canonical is shitty again and prefers to wait 5-10 years until they adopt it for Ubuntu and only after that, maybe give a hand to improve it.

Pipewire is enabled on Ubuntu since 21.04

[jabl]

AFAIU pulseaudio being a heavy user of buffer rewinding was a rich source of bugs for many years, not only in pulseaudio itself but also in drivers.

Pipewire, in contrast, is in this respect a more conservative and simple traditional audio buffer handling design that is designed to never need rewinding. Which might partly explain why it has worked well for many despite being a relatively young project.

[oiaohm]

I find it frustrating that every time a system component has reached a stable status (in this case, Pulseaudio, which is finally rock-stable after 15 years of development), it gets replaced by something else and then we get another 5-15 years of bugs and missing functionality. One can hope it's different with PipeWire, but history shows it would be a foolish hope.

The change to pipewire over pulseaudio is lot different.

That is wonderful to hear then. After years of frustration with various system component changes it would be nice to have a smooth transition for once.

Perhaps, but it works for my various devices and personal use cases these days, while it suffered from bugs/crashes/annoying behavior before.

You have to remember the lead developer of pipewire is a founding developer of gstreamer and spent 2 years+ being the redhat maintainer for pulseaudio before starting pipewire.

I guess you are not doing pro audio work.

david-nk pulseaudio was a big improvement in its day we went from having artsd under kde and esound under gnome and many other sound servers under different desktop envornments under Linux being replaced with pulseaudio. One non pulseaudio sound server lived though that purge. That is jack audio.

Jack audio is heavily used in pro audio work on Linux and a few other platforms. If you attempt to use jack audio as a desktop audio server get ready to be driven up the wall. It designed to be hugely flexable as pro audio people want but its not design to be I just play and the audio all correctly links up to output.

Pulseaudio and jack audio have end up having to the audio output device shuffle that sometimes does not work.

This is where pipewire comes in. Jack audio meta data on audio streams for what jack audio need todo cannot be completely stored in Pulseaudio audio meta data. Yes Pulseaudio audio stream meta data cannot be stored completely in jack audio stream meta data. So basically jack audio and pulseaudio are are in fact incompatible with each other. Interesting enough pulse audio and jack audio stream meta data can be completely stored in pipewire meta data. Pipewire first goal was to support video not audio so has been built with ability to support larger and more complex mete data than either jack audio or pulseaudio. So the reality here pipewire is the middle protocol of compatibility.

So pipewire can perfectly act as if it a jackaudio server and a pulseaudio server at the same time so removing the need to switch audio outputs between sound servers. Yes the fact pipewire is able to be a jackaudio and pulseaudio servers means applications don't have to be recoded in most cases to support pipewire. There have been a handful of applications that have required minor fixes. This is mostly because pipewire did something minorally different to general with either jackaudio or pipeaused that that in most cases turns out not to be a breach of jackaudio or pulseaudio but the application depend on some undefined behavour of jackaudio or pulseaudio. Yes when I say undefined behavour this is behavour that on a different hardware setup that both jackaudio and pulseaudio is allowed to-do what pipewire did to the application leading to the malfunction. Yes if it case that pulseaudio or jackaudio server could not end up with the behavour and its pipewire emulation of pipewire or jackaudio that is defective pipewire is fixed not the applications.

Also due to the pipewire protocol being able to store all the jackaudio meta data and more its absolutely possible with pipewire in future that it be sitting on top of jackaudio for ultra low latency audio work yet jack interface on top of pipewire(for sandbox reasons) be fully routing all the way though pipewire to the jackaudio under it.

The migration to pipewire from pulseaudio is going to a lot like the migration fro esound to pulseaudio mostly seamless. Debian not planning for pulseaudio to be default until at least debian 12 at this stage.

Finally getting down a single sound server that can cover 99.99% of use cases will make Linux audio a lot less problem. Pulseaudio covers about 85% to 90% of use cases. The .01 percent there will be the horrible cases where you are doing something that requires truly absolute low latency and the extra meta data over pipewire is too much overhead. So that .01 percent will not be current use case that you currently use Pulseaudio for.

Also do remember that pipewire started for Video. So maintain sync information between video being displayed and audio output as well as video input and audio input is something else the pipewire metadata is designed to store. pipewire is a many times broader tool than the prior sound servers include jackaudio and pulseaudio.

[user1]

Red Hat to VLC: No soup for you!

She's probably upset that VLC uses Qt instead of GTK with client side decorations.

[patrakov]

AFAIU pulseaudio being a heavy user of buffer rewinding was a rich source of bugs for many years, not only in pulseaudio itself but also in drivers.

Pipewire, in contrast, is in this respect a more conservative and simple traditional audio buffer handling design that is designed to never need rewinding. Which might partly explain why it has worked well for many despite being a relatively young project.

You may want to re-watch my anti-rewind propaganda from 2015: https://lac.linuxaudio.org/2015/video.php?id=8, and yes I am glad that Pipewire does not use rewinds.

[caligula]

I find it frustrating that every time a system component has reached a stable status (in this case, Pulseaudio, which is finally rock-stable after 15 years of development), it gets replaced by something else and then we get another 5-15 years of bugs and missing functionality. One can hope it's different with PipeWire, but history shows it would be a foolish hope.

I'm pretty sure Pulseaudio continues to work. They even have new releases after "everyone" switched to Pipewire.

[caligula]

Finally getting down a single sound server that can cover 99.99% of use cases will make Linux audio a lot less problem. Pulseaudio covers about 85% to 90% of use cases. The .01 percent there will be the horrible cases where you are doing something that requires truly absolute low latency and the extra meta data over pipewire is too much overhead. So that .01 percent will not be current use case that you currently use Pulseaudio for.

I wonder if Pipewire actually complicates the audio playback for simple use cases. Many systems have multiple outputs. Like when you have three monitors with integrated speakers, onboard 7.1 HD audio, iGPU with HDMI audio output, other GPU with HDMI audio output, USB headset, audio via bluetooth. The mixer is full of different controls, but in and out. Now you can also draw routing graphs with DSP effects.