https://bugs.kde.org/show_bug.cgi?id=520009
--- Comment #12 from Felix Xie <[email protected]> --- Updated findings on the root cause of the timing issue: After further testing with microsecond-level logs (journalctl -o short-precise), I have refined my understanding of why the RAOP module affects the login sound. It is not just the presence of the module, but specifically the network discovery delay it introduces. On my local network with multiple devices, the RAOP module takes a significant amount of time to scan for sinks. This incidental delay acts as a "buffer," allowing WirePlumber enough time to fully initialize the hardware sinks before Plasma triggers the login notification. I have confirmed this via a "controlled failure" test: 1.Wi-Fi ON (Multiple devices present): The discovery process is slow, the delay is long enough, and the login sound plays correctly. 2.Wi-Fi OFF: There are no network devices to discover. The RAOP module finishes its check almost instantaneously. Without this "incidental delay," the race condition occurs: Plasma triggers the sound before the audio stack is ready, and the login sound is lost. This proves that the current audio notification system is inconsistently "borrowing" startup time from an unrelated network discovery process. When that process runs too fast (e.g., no network) or is disabled, the synchronization fails. -- You are receiving this mail because: You are watching all bug changes.
