Wim Taymans wrote on Tue, Dec 15, 2020:
> In particular I'm worried alsa programs will stop working.
There is a pipewire-alsa package to support alsa programs
Aha! I had missed it, thanks.
> Shouldn't the alsa-plugins-pulseaudio also be compatible
> pulseaudio implementation?
It is but then you go through an extra layer of emulation, it's better to
remove the pulseaudio one and use the pipewire one if you remove the
Definitely, I agree pipewire-alsa suffices and is better (although I'm
not sure alsa-plugins-pulseaudio should have unfullfilled dependncies
from pipewire-pulseaudio, it's probably saner to have it autoremoved by
default to avoid multiple interfaces to the same service)
> or some new alsa-plugins-pipewire should be pulled in at least
> keep things working one way or another)
Yes, it should somehow be pulled in, how should that be done? A Suggests:
for pipewire-pulse maybe?
I'm not too familiar on this, but a recommends (rather than suggests
which will likely be ignored by dnf afaiu) on pipewire-pulseaudio sounds
good despite being not directly related to pulseaudio.
I'm honestly not sure what would be best, but pulling it without the
pipewire service enable sounds more harmful than good...
pipewire-pulseaudio sounds like a good reinsurance that pipewire will
likely be running.
Note: I've now switched packages and also had to enable/start the
systemctl --user enable --now pipewire-pulse.socket
I would suggest installing a preset file that would tell systemd to
enable it by default if possible?
It looks like pipewire.socket has one from
fedora-release-common-33-2.noarch) which wasn't obvious to find, I
didn't check if fedora34 also enables pipewire-pulse but if not it
definitely should (or pipewire should ship its own presets)