Pipewire: works.
Pulseaudio: worksn’t.
Really, it’s as simple as that. Pulseaudio tried to be the systemd of sound and
failedsucceeded 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.
This was back in kernel 2.2 / 2.4 days when Xfree86 still needed a configuration file
If you used DE’s like Enlightenment or multiple desktops simultaneously, it only caused more issues.
Also, you HAD to configure what sound server you were using often in many apps, and I seem to recall even needing to set a path in some cases to the dev.
Pulseaudio was only problematic when it was first released.
You may have had a good experience with sound servers back then, but for the rest of us, it was a lot of additional configuration and messing around
Xfree? Who’s talking about that? I’ve only ever had to use Xorg, and I only ever needed to touch its conf file if I needed to fiddle with the refresh rate of an external monitor. (Compared to that, its “”““modern””“” replacement Wayland doesn’t even start a full desktop session on my machine)
No, we’re talking about the crap that was PulseAudio, and how ALSA; which is unrelated to XFree, worked almost flawlessly and barely needed any configuration. Formatted my machine several times and remember there was someties a path to the dev (
/dev/sndor something like that usually, I think? I sometimes see it thrown around when doing advanced stuff with stuff like mpv) but I was lucky that when I had to edit my file it was for hardware bugs and not for software things. I… think? nowadays that bug is acknowledged for either at the ALSA or the Pipewire level, haven’t delved enough to check.Dealing with sound servers on the Linux community does feel like a rarity going-backwards kind of thing: to this day, Firefox for some weird ass-reason dropped ALSA support in favour of PulseAudio. But in Debian, the packaged Firefox versions continue to work with ALSA flawlessly - as if support never was dropped, despite the many versions and changes since. Which suggests me to think Mozilla never actually dropped support, they just flipped a switch somewhere to promote PA instead, which usually comes down to money deals. Mozilla is an expert at that kind of thing.
That’s my point. I’ve been using Linux from before xorg existed. Back in those days, things didn’t auto configure.
Sorry, we’ll agree to disagree here about sound servers…
Just because audio worked perfectly for you, I assure you, it wasn’t the case for everyone else at the time. Not everything defaulted to OSS or ALSA. So, there was often additional configuration involved.
And pulse was the only one to convince everyone to drop their sound servers and provide a way to support them all. That’s a huge accomplishment. Whilst it could be argued that ALSA had the potential to do so, maybe… But they didn’t
It was such a pity they didn’t include JACK support though, because that seriously held back the Linux Music production community (which is mostly seamless in Windows and MacOS)
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
screenanddtach, were discused.It’s not all FOSS it’s just those projects. You don’t have to use Gnome.
But their choices do impact other projects. I may not use Gnome, but the choices made on theming (or lack of) , for example, now also effect XFCE.
pipewire simply eliminated all the quirks from my use case.
the transition was annoying, but i don’t even think about how bad linux audio used to be anymore.
wish the transition to wayland was going this well.
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.
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.
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.
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.
I always had trouble with the sound on video calls with PulseAudio. Since I’ve switched to Pipewire, everything has been smooth.
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 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.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 greeterand 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 :)
This is just generally how you should restart most things on systemd systems.
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.