Description of problem: I am running Fedora 18, and there seems to be a big delay before any system sounds are played. For example: - When I log in (to KDE), I don't hear the startup sound for 10-15 seconds - If I do something that causes KDE to pop up a warning window (e.g., closing a system settings window with un-saved changes), the "bing" sound plays about a second after the window pops up - If I use gcompris (educational software), the sound effects occur perceptibly after the event they correspond with - If I start gcompris immediately after logging in, I don't hear any sounds initially; then, the delayed KDE login sound finally plays, and then I hear all of the batched up gcompris sounds But: - Playing audio with paplay or amarok doesn't have any delay - Using Flash in my web browser also has no audio issues My sound hardware is as follows: 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04 Version-Release number of selected component (if applicable): pulseaudio-2.1-4.fc18.x86_64 How reproducible: Every time Steps to Reproduce: 1. See above Additional info: Fedora 17 on identical hardware does not have these issues
Hi, FYI: On de kde-fedora mailing list there was a discussion [1], [2] about the same problem. To my knowledge it is never solved. The delay started after the update to kde version 4.9.x Hope this can help a little, Martin Kho [1] http://lists.fedoraproject.org/pipermail/kde/2012-August/011857.html [2] http://lists.fedoraproject.org/pipermail/kde/2012-November/012025.html and follow ups.
Created attachment 658388 [details] pulseaudio log from one KDE system sound Here's the first of two pulseaudio logs. In this one, I caused one KDE system sound to play (search for "knotify") -- the "bing" noise happened about a second after the corresponding dialogue box.
Created attachment 658389 [details] pulseaudio log from a brief interaction with gcompris This log shows the output from running gcompris briefly and doing one activity. All sounds were very delayed.
Does the patch from bug 888422 have any influence?
I haven't tried that patch yet -- but I have updated to pulseaudio 3.0 from rdieter's "pulseaudio-backports" repo and that also fixed the problems. I see that a new update of pulseaudio has been pushed with the patch from that bug included. I'll try that out over the weekend.
*** This bug has been marked as a duplicate of bug 888422 ***