Two days ago the wireplumber package was made to replace pipewire-media-session as the latter session manager for PipeWire is considered dead upstream and will see no more releases. Unfortunately, this step was premature.
Our pipewire audio packages (pipewire-alsa, pipewire-jack and pipewire-pulse) ship configuration that prompt media-session to activate PipeWire’s audio features. When these packages are not installed and the configuration is missing, PipeWire can be used for screen recording without interfering with ALSA or PulseAudio.
WirePlumber disregards this mechanism and always configures PipeWire to grab audio devices, meaning users of PulseAudio or bare ALSA experience broken audio.
The replacement has been reverted while we attempt to look for a better solution switching to WirePlumber. If you are currently not using PipeWire for audio and wireplumber got installed on your system, please reinstall pipewire-media-session and reboot to restore audio functionality.
So here’s the problem: if you were running pulseaudio then the wireplumber daemon will not let pulseaudio play audio, and therefore pulseaudio will break.
If you switch to pipewire then all media will work, but then I was curious to see why MPRIS was not.
Running systemctl --user status wireplumber, I found the following error message
It seems that wireplumber destroys the mpris-proxy daemon, and therefore pausing and playing from bluetooth headsets no longer works.
To fix my MPRIS issue I did the following:
switch back to pulseaudio
disable the wireplumber systemd service
rebooted
PS: It still seems that wireplumber randomly starts at boot whenever it wants, so make sure to add killlall wireplumber as a startup command in your desktop environment/window manager
Now all audio is playing and MPRIS is working fine. Since this issue was only introduced in this unstable update, it isn’t very well documented, so I’m gonna leave some SEO keywords here so that people with the same problem can easily google it and run into this post.
search keywords
mpris-proxy not working pipewire, mpris not working pipewire, pulseaudio audio not working, mpris pipewire, mpris wireplumber, mpris not working manjaro, cant pause and play bluetooth audio pipewire
For some reason the vmmon module which is relevant for the VMware Network Stack is missing. On 5.15.39 (tested) not sure if this is the case for all kernel series.
Even if headers are installed.
Would it be possible to decouple the dependency between malcontent and flatpak?
malcontent is a dependency for gnome-control-center and it means by extension gnome-control-center requires flatpak.
And I absolutely don’t want flatpak installed on my system. I resorted to a different control center for now.
Thanks for the follow-up!
Hopefully, this allows for a snapflatpak-free experience.
Once flatpak is installed, it means open days and any flatpak packaged app can be installed without my consent or even me noticing.
In my opinion, going back to the medieval Windows computer era of bundled packages and unshared libraries is really not a good prospect for the future. I want to avoid this at all costs.
Systemd 251 is out with a lot of major changes. The minimum kernel version required has been bumped from 3.13 to 4.15. This of course means Manjaro will have to drop the 4.9 and 4.14 LTS kernels.
@philm wants to wait because major Systemd releases can cause issues and it may take a point release or two to iron out bugs.
Arch has had the two release candidates in their Testing branch for over two weeks. The stable 251 release is now in Arch Stable.
What you do think?
Bring it on! Bugs be damned!
No! I’m too scared
0voters
P.S. I already built it and installed it. Running fine so far…
This and and approaching Plasma 5.25 with lots of under the hood changes makes me want to switch branch to Testing or postpone updates until first point releases are rolled out
But why not, really. I have backups anyway. Rock on!