Pipewire-pulseaudio issues, anyone out there to assist please - FIXED

Ask Fedora
,
23

Posting here because I had some similar symptoms to people on this thread, but not exactly the same.

Problems:

  • After resuming from suspend, I had audio/video problems. I could 100% reliably reproduce these by sleeping and then waking the PC:

    • YouTube videos would hang in Firefox
    • The KDE Plasma volume control / audio device selection widget would behave weirdly (for example, trying to change the default output device using the radio button would end up with both radio buttons highlighted, but no working audio)
    • Whenever this happened, it was resolved by systemctl --user restart wireplumber pipewire pipewire-pulse

  • Sometimes, but not always and not reproducibly, I got the same problem that @alienkidmj12 described, where it took a long time to get from SDDM into the Plasma desktop.

    • The logs showed that it was indeed trying and failing to play a sound like @alienkidmj12 suggested:
      Sep 13 20:34:47 sddm-helper-start-wayland[3424]: "QSoundEffect(pulseaudio): Error decoding source file:///usr/share/maliit/keyboard2/sounds/key_tick2_quiet.wav\n"
    • Whenever this happened, the Plasmashell would invariably crash within a minute and throw me into an SDDM login loop
    • Journal logs showed this error during the suspend process:
Sep 13 20:29:35 wireplumber[2497]: wplua: [string "device-info-cache.lua"]:36: attempt to call a nil value (field 'critical')
                                   stack traceback:
                                           [string "device-info-cache.lua"]:36: in function 'device-info-cache.get_device_info'
                                           [string "state-routes.lua"]:185: in function <[string "state-routes.lua"]:179>
                                           [C]: in ?
                                           [C]: in method 'advance'
                                           [string "state-routes.lua"]:172: in function <[string "state-routes.lua"]:167>

This started in the last few days, over the period where there have been several 6.16.x kernel updates, but it’s not a kernel problem because I can reproduce it on 6.15.9.

I followed @josevillani 's suggestion of downgrading to wireplumber-0.5.10-1.fc42 and this seems to have fixed it.

But the similar downgrade didn’t work for @theprogram so I don’t know if 0.5.10-2.fc43 is slightly different to 0.5.10-1.fc42.

This Bugzilla ticket seems to be related (the same Lua stack trace that I’m seeing):