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 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
brokenincompatible X11 is (and there is XWayland for most clients that mostly works)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.
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
it’s strange restrictions on behavior and overlays
Ain’t this is good for security and privacy?
A “security” that interrupts the user or prevents them from doing their work is bad, because it incentivizes the user to skip or disable it, and the use of a Linux system already can get most of the ways to do either of those via
${packagemanager} install. Thus it’s more like security theatre.From what I gather, the wayland model of things is so ridiculous that it can’t even provide for global hotkeys - which are, like, the guaranteed way to setup an interface the user can trust because it’ll always mean that when the user users it. I doubt wayland would even be Magic SysRq keys-compatible.
What the other person said. I didn’t even think magic sysrq keys I was thinking like some steam like overlay lmao
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: works.
Does it have jack support? I have a network sound server and I use both linux and windows clients. I solved windows clients with the jack plugin.
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
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.
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.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.
To be fair (with pipewire*) my audio issues usually related to HDMI audio output which has been a PITA for like 20 years since the days of Xbox 360.
I started using PipeWire as soon as Arch switched the recommended default and I agree, it cleared up a lot of issues and fixed my Bluetooth headset, which was nice.
My 3.5mm issues are complicated by the scenario where I have a extension cable always plugged in but not always my headphone cable (sennheisers stock cables aren’t super long)
I just wanted to add this as a “to be fair” and there is a element of “user error” where I just haven’t put enough time in to really learn pipewire.
Well last night I resolved my problems by making sure to kill all processed owned by the greeter (as seen in my other post thanks to OP^^)
`killall -u greeter’
Now I can enjoy my Ubuntu startup sound in peace /s /volume-warning
Pipewire was honestly the most pain-free introduction of a new audio technology on Linux; it was a nice change of pace.
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.
