I’ve been using PipeWire this year on my Void Linux laptop & desktop. It’s been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
I don’t have to use Chromium for my mic to work on online video conf (WTF Firefox)
“EasyEffects” lets me quickly fix crappy youtube audio (bad gain normalisation, way too much sibilance) with a minimum of effort.
Cons:
Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
First time setup is complicated, involving environment variables, dbus user session buses and multiple daemons (running just pipewire isn’t enough). Why can’t it handle this all itself? Surely it should notice if these things are missing and just fix it itself? Compare this to straight ALSA where you (1) do nothing and then (2) everything works (except Firefox mic support)
I can’t have multiple audio outputs all unmuted at the same time. Eg my headphone output and my rear speaker output. If I override this (using alsamixer) then it gets forgotten next boot anyway, it seems to be out of scope of PipeWire’s understanding.
I can’t say I share your experience. There were a few packages I needed to install (pipewire, pipewire-pulse, and wireplumber) but after an apt install I was pretty much good to go, were it not for the fact Pulseaudio was already running and enabled so not all of Pipewire autostarted by default.
Had to enable it of course (systemctl --user --enable) because it inherently conflicts with Pulse, but on systems that now ship with Pipewire by default, that’s all done for you. Only config I ever messed with was forcefully enabling mSBC and SBC-XQ to get higher audio bitrates over Bluetooth.
I think the packaging on the more “hardcore” distros is intentionally dynamic because some people may prefer to keep Pulseaudio, but enable Pipewire for video capture on Wayland. Not many applications make use of it, but Pipewire can so route video streams. Installing both pipewire-pulse and Pulseaudio will lead to a race condition on which audio subsystem is used if both are enabled by default.
I’m not sure what limitations you have with your use of different outputs. It’s possible that pipewire-pulse doesn’t expose all data for Pulse software to properly route audio to multiple devices, but Pipewire itself can do it. I’ve used qJackCtl (and pw-jack) to send audio channels through different filters and then to different output devices, the underlying system is very capable.
I know my Gnome setup likes to undo all manual audio routing when I plug in an audio device, but I’m too lazy to look into how I would fix that. It may be related to some PulseAudio wrappers? Worth noting that I had the same problem on Pulseaudio, which makes me suspect it’s a Gnome thing.
Sometimes breaks all audio until I manually restart it (hey, just like pulseaudio. This problem never happens when using ALSA straight)
Well, how much lennart is in this thing? Not only can that predict how well it’s going to work, but also how soon it’ll be fixed, how responsive the ‘team’ will be to bug reports, how compatible it’ll be with other system components AND whether ‘compatibility’ will be achieved before the entire OS has been systematically imported into (and badly replicated by) the project.
If you check SystemD, its a HUGE step up, which is why everyone is using it now (whereas, the old scripts had race conditions, were a pain to write and other issues). Anyone who has written both can tell you how much better things are now…
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
And honestly, the situation before PulseAudio was awful. Audio not working was a common issue, and low latency audio was the least of anyone’s problems. Whereas, these days, because of Pulseaudio, even gaming is a thing now (back then, I even saw issues on tuxracer, and Unreal tournament back in the days).
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us). In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
If you check SystemD, its a HUGE step up, which is why everyone is using it now
I think that’s a “winners write history” situation. There were other options at the time that might have been better choices. Everyone uses it now because of Redhat and Debian being upstream to most users, desktop and corporate. I was not surprised by Redhat adopting it (it’s their own product) but Debian was quite the shock.
Yes systemd is definitely a step up from traditional initscripts (oh god). In terms of simplicity, reliability and ease of configuration however it’s a step below other options (like runit). I don’t have distro management experience but, given the problems I’ve encountered with different init systems over the years, I suspect there would be less of a maintenance burden with the other options.
I’m very curious about the downvotes to this one. May I ask people’s thoughts? Perhaps I’m too vague? I can put a bigger story about my experiences with various init systems in production & research if people are interested.
I’ve been using PipeWire this year on my Void Linux laptop & desktop. It’s been mostly OK but has a few problems. For years I have been using plain ALSA (with no custom configuration) because pulseaudio causes me regular issues across multiple machines (mostly silently failing).
Pros:
Cons:
I can’t say I share your experience. There were a few packages I needed to install (pipewire, pipewire-pulse, and wireplumber) but after an apt install I was pretty much good to go, were it not for the fact Pulseaudio was already running and enabled so not all of Pipewire autostarted by default.
Had to enable it of course (systemctl --user --enable) because it inherently conflicts with Pulse, but on systems that now ship with Pipewire by default, that’s all done for you. Only config I ever messed with was forcefully enabling mSBC and SBC-XQ to get higher audio bitrates over Bluetooth.
I think the packaging on the more “hardcore” distros is intentionally dynamic because some people may prefer to keep Pulseaudio, but enable Pipewire for video capture on Wayland. Not many applications make use of it, but Pipewire can so route video streams. Installing both pipewire-pulse and Pulseaudio will lead to a race condition on which audio subsystem is used if both are enabled by default.
I’m not sure what limitations you have with your use of different outputs. It’s possible that pipewire-pulse doesn’t expose all data for Pulse software to properly route audio to multiple devices, but Pipewire itself can do it. I’ve used qJackCtl (and pw-jack) to send audio channels through different filters and then to different output devices, the underlying system is very capable.
I know my Gnome setup likes to undo all manual audio routing when I plug in an audio device, but I’m too lazy to look into how I would fix that. It may be related to some PulseAudio wrappers? Worth noting that I had the same problem on Pulseaudio, which makes me suspect it’s a Gnome thing.
Well, how much lennart is in this thing? Not only can that predict how well it’s going to work, but also how soon it’ll be fixed, how responsive the ‘team’ will be to bug reports, how compatible it’ll be with other system components AND whether ‘compatibility’ will be achieved before the entire OS has been systematically imported into (and badly replicated by) the project.
I don’t think honestly he gets enough credit.
If you check SystemD, its a HUGE step up, which is why everyone is using it now (whereas, the old scripts had race conditions, were a pain to write and other issues). Anyone who has written both can tell you how much better things are now…
The fact this issue is happening on both Pipewire and Pulseaudio also suggests it’s more likely a bug in the drivers… It might not be obvious on ALSA directly, but that doesn’t mean an issue doesn’t exist there…
And honestly, the situation before PulseAudio was awful. Audio not working was a common issue, and low latency audio was the least of anyone’s problems. Whereas, these days, because of Pulseaudio, even gaming is a thing now (back then, I even saw issues on tuxracer, and Unreal tournament back in the days).
In regards to setup, most distributions will handle that anyway I’m guessing. So not sure why the configuration process should matter unless you’re in Arch or Slackware? As long as the distribution handles it, it shouldn’t matter. It’d really a non-issue honestly.
I do a lot of middleware development and we’re regularly blamed by users for bugs/problems upstream too (which is why we’ve now added a huge amount of enduser diagnostics/metrics in our products which has made it more obvious the issues aren’t related to us). In practice, very few people have issues with Pulseaudio (I haven’t seen issues since launch). Sometimes as well, keep in mind it can be the sound interface (especially if its USB)
I think that’s a “winners write history” situation. There were other options at the time that might have been better choices. Everyone uses it now because of Redhat and Debian being upstream to most users, desktop and corporate. I was not surprised by Redhat adopting it (it’s their own product) but Debian was quite the shock.
Yes systemd is definitely a step up from traditional initscripts (oh god). In terms of simplicity, reliability and ease of configuration however it’s a step below other options (like runit). I don’t have distro management experience but, given the problems I’ve encountered with different init systems over the years, I suspect there would be less of a maintenance burden with the other options.
I’m very curious about the downvotes to this one. May I ask people’s thoughts? Perhaps I’m too vague? I can put a bigger story about my experiences with various init systems in production & research if people are interested.