PipeWire is great.
I remember a lot of people kicking up a fuss about it years ago saying it’s a mess and we should stick to PulseAudio or routing audio to ALSA, but personally for me it’s been great, far less troublesome than previous solutions, and the vast majority seem to agree.
The pain points were short-lived and now we’re reaping the benefits of having a modernised, easier to maintain, less janky system. Credit to the devs, and to the distros who pushed it.
The latency is insanely low on Pipewire, which is important for rythm games like osu!, that’s why I originally switched to it. It’s also really cool how it’s compatible with all other audio backends as well.
deleted by creator
There was a similar fuss when distros moved from alsa to pulse.
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 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.
Both were just a pain in their own right, IMHO. My previous Focusrite interface was quite fiddly to get working with ALSA and just worked OOTB with Pulseaudio. I also don’t miss messing with ALSA/JACK at all.
Pipewire has pretty much been a drop-in replacement for me, with how it can act as a Pulseaudio backend.
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.
With Wayland it was either break everything and improve, progress, and innovate over time with something actually maintainable & expandable,
Or… make x11\Xorg 2.0 and have to rewrite the entire stack yet again in only a few years.And it was the X devs who made the choice.
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.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 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).
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
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.
Really? Like not letting apps draw over other apps? As far as I know Windows still allows that, so does even Mac OS. I don’t know who in the industry decided that screenshotting is a bad behaviour and needs to be removed but maybe they should find a new industry, like fast food line work for example.
Allowing any app unrestricted access to the input and output of any other app (like in X11) is a terrible security practice. It allows for trivially easy keyloggers and makes horizontal movement to other apps after the first has been exploited super easy.
Many people’s answer to this is “then just don’t run untrusted apps, duh”, but that is a bad take since that isn’t realistic for 99% of users. People run things like Discord or Spotify or games or Nvidia drivers all the time, not to mention random JavaScript on various websites, so the security model should be robust in the presence of that kind of behaviour. Otherwise everyone is just a single sandbox escape in the browser away from being fully compromised by malware installed with root privileges. Luckily we know better now than when X11 was designed and that is the reason for things like Bubblewrap (used in Flatpak for sandboxing), portals and the security model of Wayland.
And in the end: the people who decided this are the people actually willing to do the work to build and maintain the Linux desktop stack. If anyone knows what the right approach is, it’s them.
X11 doesn’t have to allow any app unrestricted access to any other app.
But it was the X protocol that needed to be replaced.
And it hasn’t done that because no one is going to replace it a good but old pipe with a few issues with a pipe with a massive hole in it “by design”
