Pipewire vs PulseAudio: What's the Difference?
Pipewire vs PulseAudio: What's the Difference?

Pipewire vs PulseAudio: What's the Difference?

Pipewire vs PulseAudio: What's the Difference?
Pipewire vs PulseAudio: What's the Difference?
Pipewire: works.
Pulseaudio: worksn't.
Really, it's as simple as that. Pulseaudio tried to be the systemd of sound and failed succeeded pretty horribly. Even its packaging was horrible, back when it was first put into Fedora and I tried uninstalling, it threatened taking down Libreoffice and Gedit with it.
Pulseaudio is NOT a failure lol
ALSA, Esound, OSS etc were always conflicting pre-pulseaudio. Sometimes you'd get sound, you'd always have to screw around with the sound server settings in different apps between KDE and Gnome apps, and gaming was a disaster. Even just using XMMS2 was a pain with Netscape/Firefox
It was a huge step forward, even with initial teething problems.
The only thing it didn't solve was low latency (for music production), and that's really the huge advantage of Pipewire. It did take a while to get there though..
In Xfree86 days, Linux wouldn't have had a future if PulseAudio wasn't released. It was one of those critical elements (along with Compiz, XrandR, DRI, Udev, PackageKit and Steam) which actually made Linux competitive against OSX and Windows at the time
I don't know what universe were you living in, but I remember history vastly differently. No app I ever used ever had problems with ALSA, not even gaming. XMMS or XMMS2 (or Audacious even back then when it was kinda starting) never had issues with Firefox. Only when PA was introduced I started losing audio on various apps, losing volume control, or in a few cases apps would cease listing ALSA as a possible audio output while PA was installed.
I killed PA on my machines hard and never had any issues again, and things pretty much only improved once Pipewire arrived other than having to change one (1) configuration file, and it was properly documented.
back when it was first put into Fedora and I tried uninstalling, it threatened taking down Libreoffice and Gedit with it.
I did this back when I was a newbie and somehow destroyed either the display server or some other part of the GUI. Sound issues have made me nervous ever since.
Well that's just poor packaging.
Shoddy workmanship due to how eager those devs are to push their beta testing software on Production, yeah. And honestly looking back, coming from Fedora, doesn't surprise me.
IIRC wasn't Pulseaudio and systemd made by the same person?
No idea if that's the case but they certainly seem to have been made with the same mentality. FOSS has for a while suffered of what I call the "Icaza pest", trying to bring the Microsoft way of design and programming into Linux. The results and troubles this causes abound, considering eg.: the fart that has been Gnome themes since 3.x, or the Gnome posturing back in the day that "users have no right to change their settings" when modernization of Gnome-terminal, and how it'd interact with stuff like screen
and dtach
, were discused.
PipeWire wins in the feature-set game, which is why it is being preferred over PulseAudio.
According to the inventor of PipeWire, this is the wrong perspective to take. PipeWire is preferred over PulseAudio as a server, clients (apps) should continue to use the PulseAudio/JACK APIs because the PipeWire API is not designed for general use (it's designed for things like pipewire-pulse and pipewire-jack).
clients (apps) should continue to use the PulseAudio/JACK APIs because the PipeWire API is not designed for general use
Really? That is news to me ... explains why mpv's pipewire audio output was briefly broken a couple of months ago.
I heard it in a podcast, but here's a written source on that: https://fedoramagazine.org/pipewire-1-0-an-interview-with-pipewire-creator-wim-taymans/
The message is still to use the PulseAudio and JACK APIs. They are proven and they work and they are fully supported.
I know some projects now use the pw-stream API directly. There are some advantages for using this API such as being lower latency than the PulseAudio API and having more features than the JACK API. The problem is that I came to realize that the stream API (and filter API) are not the ultimate APIs. I want to move to a combination of the stream and filter API for the future.
So the middleware stays the same but the underlying server changes? That's an amazing strategy I wish Wayland did this instead of breaking damn near everything with it's strange restrictions on behavior and overlays
The thing with Wayland and X11 is: this couldn't really be done because of how fundamentally broken incompatible X11 is (and there is XWayland for most clients that mostly works)
That's what xwayland is.
Apps can talk to xwayland with the x11 protocol but instead of an X server rendering it, your Wayland compositor renders it.
The restrictions come from the fact that those x11 behaviours are exactly things the industry has decided are a bad idea and should be replaced.
Yeah it's kinda the opposite of "New interface, old implementation."
Which I learned from https://henrikwarne.com/2024/01/10/tidy-first/
But it was the X protocol that needed to be replaced.
As someone who occasionally dabbles in music production on Linux, I love that Pipewire lets me run JACK and Pulseaudio apps side-by-side without having to jump through hoops.
Pipewire was honestly the most pain-free introduction of a new audio technology on Linux; it was a nice change of pace.
Yeah. PulseAudio is made by the same wunderkind who brought us fucking systemd.
I always had trouble with the sound on video calls with PulseAudio. Since I've switched to Pipewire, everything has been smooth.
I miss the pulseaudio restart command.
Sometimes my 3.5mm aux isn't detected in pipewire until I reboot.
pulseaudio -r used to do the trick iirc
On my distro (debian) I can use systemctl --user restart pipewire.service
.
This is just generally how you should restart most things on systemd systems.
Thank you, I added the command to my Linux Journal,
Your post motivated me to do some more trials and it ended up that my greetd greeter was locking up the audio sink.
So I made sure to add a command after the greeter exits killall -u greeter
and the sink finally passed correctly to the logged in user just fine after that.
In reviewing the arch wiki some more too I've installed wire plumber session manager for pipewire, I am still a little confused about it's function and relation to pipewire but maybe that has helped too?
Cheers :)
I used to have to occasionally run this but I'd say it has been at least a couple of years since I last had to. I was a pretty early adopter of pipewire because it solved some Bluetooth issues that pulseaudio had. It has improved immensely since I first started using it.
Would love to use it, it has the incorrect channel map for my surround sound system which apparently cannot be changed like it can in pulse? After that gets sorted then sure.
my system sets the wrong bitrate for a device but I was able to configure it, you may want to browse the wireplumber wiki and see if its config options can meet your use case
That's a good tip, it probably can but I'll need a bit of learning to figure it out. The Linux audio situation is a hell of a learning curve sometimes.
I've been using Pipewire for a while, it was great because I could use my Bluetooth headset with a better audio Codec than in Pulseaudio. Unfortunately, my headset stopped working one day suddenly with Pipewire. (maybe after a dist-upgrade?) No amount of disconnecting, unbonding etc. would work. Went back to Pulseaudio as a sound server. Sad.
Neither Pulseaudio nor Pipewire remember to use by screen speakers (hdmi) as default, though. It always switches back to the internal sound card.
The transition for me was "install Pipewire and its pulseaudio compatibility package, remove pulseaudio, reboot."
There are a couple of quirks (updating Apparmor rules makes KDE think I've reattached all my audio devices), but it's mostly pretty smooth.