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).
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)
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.
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).
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/
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
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