Pipewire vs PulseAudio: What's the Difference?

And rightly so. There's a reason we're migrating away from pulse to pipewire.

For the longest time the solution to any audio issues was "just uninstall PulseAudio, and use plain ALSA", and that usually worked. I held out for years and ran an ALSA only setup because it just worked and PulseAudio was always giving me one issue or another (audio lag, crackling, unexplained muting), until some applications started to drop ALSA support.

Then Pipewire came along, and so far it has been rock solid for me.

Having been a linux user around the time of both rollouts I've had a way better time with pipewire. We've come a long way since OG pulseaudio

And it was the X devs who made the choice.

I waited for canonical to enable it by default. The annoying part for me was undoing the workarounds PulseAudio needed to do what I wanted.

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.

Pipewire's got fantastic JACK support. You can even run standard JACK control GUI's like Carla on top of it and expect them to work just like they would on regular JACK

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.

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.

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.

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.

it’s strange restrictions on behavior and overlays

Ain't this is good for security and privacy?

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.

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.