https://bugs.kde.org/show_bug.cgi?id=493962
--- Comment #28 from Sebastian E. <kde-b...@foobarlibre.net> --- @Eugene: You posted the specs of an "old test notebook" where you do *not* have the issue. I'd like to know the specs of the affected workstation (the video looks like there are some professional audio applications involved, so I'd guess its CPU is on the higher end). @all: I'm asking because there seem to be duplicates involved (i.e. the state of pulseaudio-qt gets out of sync with PipeWire), and there seems to be a race condition at initialization time which determines whether duplicates can occur or not. I only have little experience with C++/Qt, but I'd dare to suggest that the race condition might be there: https://invent.kde.org/libraries/pulseaudio-qt/-/blob/cb8bea910475a0822d39fa8c1ccd6fe3d1e795d0/src/context.cpp#L265 Either connectToDaemon() succeeds immediately, before the constructor finishes and all signals/slots are connected—or it's called later (maybe from another thread) after the constructor has finished (or maybe even in-between). That depends on whether the D-Bus service is already registered (i.e. pipewire.service and pipewire-pulse.service are up) when that code is executed. I experimented a bit further, trying to ensure either condition, though not enough to make a call. However, I think things go wrong when PipeWire is already up, which is more likely with more CPU cores (I've got an AMD 5950X). Performance improvements with newer kernels might also tip the scale, but at first glance those coming with kernel 6.11 don't affect my CPU. -- You are receiving this mail because: You are watching all bug changes.
