https://bugs.kde.org/show_bug.cgi?id=520009
--- Comment #8 from Felix Xie <[email protected]> --- The logic in /usr/share/pipewire/pipewire.conf.avail/50-raop.conf indicates that libpipewire-module-raop-discover is loaded by default unless module.raop is explicitly set to false. Based on my testing, the initialization of this module likely introduces a side-effect delay that unintentionally prevents a race condition. When the module is disabled, the startup sequence appears to proceed too rapidly, causing the Plasma 6 login sound to be triggered before the audio sinks are fully exposed by WirePlumber. It is important to emphasize that disabling this module is a common necessity due to its intrusive nature. As discussed in the community (e.g., https://www.reddit.com/r/Fedora/comments/1ojgwo9/...), this feature often causes significant headaches by auto-discovering unintended network devices. One user (macboarder) perfectly illustrated the issue: "Mate, you just solved a big headache for me - whenever I forgot to plug my USB sound card back, the OS defaulted to my roommate's Sonos speaker 😅" It feels like a bit of a "luck-based" synchronization right now. Users shouldn't have to choose between hearing a login sound and accidentally hijacking their roommate's speakers. Ideally, the notification system should be able to handle its own timing explicitly, rather than piggybacking on the incidental delays of an optional (and often intrusive) discovery module. -- You are receiving this mail because: You are watching all bug changes.
