Comment 20 for bug 1897965

Revision history for this message
Alfred Aardvark (nopants) wrote :

I suspect I figured out this problem, it is a race condition between pipewire and pulseaudio that may only affect a very small number of users and only when their system configuration times the two to make the race condition happen.

After a recent update of unrelated packages, after bootup, a sound device was not correctly working anymore. Rebooting did not fix it, however logging out of kde and back in did. At first I thought the problem was SDDM related (SDDM starting too early before sound devices are fully initialized or some such) but then noticed a simple pulseaudio -k fixes it.

Forensically, I had the offending version of pipewire (0.3.10-4) installed for 3 weeks, but the problem only popped up this week, after an unrelated system update.

I got into touch with the pulseaudio devs and they immediately suspected pipewire to be the culprit, due to a race condition between pipewire and pulseaudio. apt-removing pipewire I confirm the system works as it should again. The pulseaudio devs state that pipewire >= 0.3.13 would have fixed the problem, but warned that 0.3.14 caused problems on arch, and that 0.3.16 is "latest and greatest"

Recommended course of action: Update the repositoried version of pipewire to >=0.3.16 ASAP and observe if the problem persists. Note that any change to system configuration can make the race condition appear or disappear, so if the underlying problem was not successfully fixed by pipewire, this problem could show up again because it is not easily replicable.