Created attachment 192172 [details] Visual boot chart (systemd-analyze plot) illustrating the race condition between audio services and the session. On Fedora 44 KDE (Plasma 6.6.4), the system login sound fails to play during the very first login after a cold boot. However, if the user logs out and logs back in without restarting, the login sound plays normally. Analysis of the provided systemd logs suggests a race condition: pipewire.service, wireplumber.service, and pipewire-pulse.service are started at the exact same second (e.g., 18:35:15) that the user session initializes. It appears the desktop environment attempts to play the login notification before WirePlumber has finished initializing the audio sinks or hardware (like the camera/UVC video detection shown in logs). Version-Release number of selected component: plasma-workspace-6.6.4 Reproducible: Always Steps to Reproduce: 1.Power on the computer (cold boot). 2.Log in to the KDE Plasma session via the login manager. 3.Observe that no login sound is played. 4.Log out of the current session. 5.Log in again. 6.Observe that the login sound plays correctly this time. Actual Results: Silence on the first login after boot. Expected Results: The login sound should play reliably on the first login, ensuring the audio stack is ready before the sound event is triggered. Additional Information: I have attached startup_debug.log, audio_startup_debug.log, and fedora_boot_order.svg which show the overlapping start times of the multimedia services. Operating System: Fedora Linux 44 KDE Plasma Version: 6.6.4 KDE Frameworks Version: 6.25.0 Qt Version: 6.10.3 Kernel Version: 6.19.14-300.fc44.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × 13th Gen Intel® Core™ i5-13420H Memory: 16 GiB of RAM (15.1 GiB usable) Graphics Processor: Intel® Graphics Manufacturer: LENOVO Product Name: 21KG System Version: ThinkBook 14 G6 IRL-SE
Created attachment 192173 [details] Journal logs showing the timestamps of systemd user services during the first login.
Created attachment 192174 [details] Detailed PipeWire and WirePlumber initialization logs showing concurrent startup.
I can't repro this, could this be a distribution configuration issue? Operating System: KDE Linux 2026-05-10 KDE Plasma Version: 6.6.80 KDE Frameworks Version: 6.27.0 Qt Version: 6.11.0 Kernel Version: 7.0.3-arch1-2 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
This isn't a crash, recategorizing
I have the same issue except the login sound still does not play after logging out and logging back in.
I'm able to reproduce this in Plasma built from git-master on Solus, after verifying that the login event was set to play a notification sound Cold boot - no login sound Log out and back in - sound played I've also noticed that other notification sounds don't play immediately. - Raise or lower volume on the laptop with keyboard keys The first key press produces no sound, but later ones do
Update on findings regarding pipewire-config-raop and initialization timing: I have identified the specific trigger for this issue. I originally uninstalled the pipewire-config-raop package because it was auto-discovering Apple devices (RAOP) on my local network. This discovery was causing a conflict with my "Global Mute" policy—whenever a new network device was found, the system would automatically unmute itself. I have further refined the reproduction steps and identified a specific dependency on the RAOP module's activity: 1.Package installed & RAOP enabled (Default): The login sound plays correctly on cold boot. However, auto-discovered network devices interfere with the "Global Mute" policy, unmuting the system whenever a device is found. 2.Package uninstalled: The login sound is consistently missing on cold boot. 3.Package installed & RAOP disabled via config: Even with the package present, if the module is disabled in the configuration, the login sound still fails to play on cold boot. I should also note that this appears to be a regression. In previous versions (likely prior to the Plasma 6 or Fedora 44 update), I was able to remove or disable the pipewire-config-raop module without any impact on the login sound.
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.
Created attachment 192271 [details] Timing analysis with RAOP discovery active (Login sound works) This log illustrates that when Wi-Fi is enabled, libpipewire-module-raop-discover enters an active scanning state. The extensive log noise from mod.raop-sink (starting at 20:36:10.373) confirms a heavy initialization overhead. This accidental delay acts as a "timing buffer," ensuring that WirePlumber has enough time to finish its hardware/UVC initialization (completed at 20:36:10.724) before the desktop environment triggers the login notification.
Created attachment 192272 [details] Timing analysis with RAOP discovery active (Login sound works) This log illustrates that when Wi-Fi is enabled, libpipewire-module-raop-discover enters an active scanning state. The extensive log noise from mod.raop-sink (starting at 20:36:10.373) confirms a heavy initialization overhead. This accidental delay acts as a "timing buffer," ensuring that WirePlumber has enough time to finish its hardware/UVC initialization (completed at 20:36:10.724) before the desktop environment triggers the login notification.
Created attachment 192273 [details] Timing analysis with NO network discovery (Login sound fails) In this scenario, with Wi-Fi disabled, the RAOP discovery process finishes almost instantaneously as there are no network sinks to scan. Notice that pipewire-pulse is ready by 20:32:37.401 , but WirePlumber is still processing libcamera/UVC drivers at 20:32:37.715. Without the "network-scanning delay" seen in the Wi-Fi ON case, the startup sequence proceeds too rapidly, causing the login sound to be triggered before the audio backend is fully mapped, resulting in silence.
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're not wrong about that. But there's a trade-off here: the more conditions we add to the startup-related units, the slower login is going to be most of the time for most of the people.
Seems like a duplicate of https://bugs.kde.org/show_bug.cgi?id=520009
Ugh...I meant a duplicate of https://bugs.kde.org/show_bug.cgi?id=519948
(In reply to Phil O from comment #15) > Ugh...I meant a duplicate of https://bugs.kde.org/show_bug.cgi?id=519948 Indeed, it does look like the same bug. I'll merge this in with the older report. Well spotted! *** This bug has been marked as a duplicate of bug 519948 ***