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