Description of problem: Pulseaudio daemon runs away and starts consuming 100% cpu. Only killing it restores it to normal state (it's restarted). Version-Release number of selected component (if applicable): pulseaudio-0.9.21-6.fc13.i686 How reproducible: Often Steps to Reproduce: 1. Keep using firefox, xmms Additional info: ------------------ 2431 user 9 -11 599m 4248 3172 R 99.5 0.3 118:56.93 pulseaudio 2391 user 20 0 983m 15m 11m S 4.0 1.1 46:37.58 knotify4 641 root 20 0 0 0 0 S 2.7 0.0 18:47.84 phy0 1276 root 20 0 68488 24m 6264 S 2.7 1.6 33:09.81 Xorg 2435 user 20 0 108m 20m 12m S 1.3 1.4 0:12.77 konsole 2567 user 20 0 818m 158m 26m S 1.3 10.7 80:12.04 firefox 12844 user 20 0 73324 17m 9016 S 1.3 1.2 0:20.45 npviewer.bin 12955 user 20 0 2748 1056 796 R 1.3 0.1 0:00.30 top -------------------
/var/log/messages has no relevant information when this happens.
This bug was initially opened for FC11. FC11 cycle ended, and I reopened it for FC12. FC12 ended, and I reopened it for FC13. I can reproduce it on FC14 as well now. Any progress on finding a fix for this?
Hi, Uday ! I am with the same issue. Is your sound hardware a HDA-INTEL like mine ? This problem was ocurring in all start up, after i installed F15. My previous F13 was just fine. Then, in my bogus F15, i have marked the option "use a external player" in : System Setting->Applications & System Notifications->Player Setting I choose /usr/bin/ogg123 as the player. The bug stopped. It only reappears when a printer error occurs. Then, a lot of : Sep 10 14:26:17 pandora pulseaudio[1412]: ratelimit.c: 180 events suppressed Sep 10 14:27:36 pandora pulseaudio[1412]: ratelimit.c: 177 events suppressed Sep 10 14:28:01 pandora pulseaudio[1412]: ratelimit.c: 172 events suppressed Sep 10 14:28:31 pandora pulseaudio[1412]: ratelimit.c: 198 events suppressed Sep 10 14:28:50 pandora pulseaudio[1412]: ratelimit.c: 200 events suppressed Sep 10 14:29:07 pandora pulseaudio[1412]: ratelimit.c: 198 events suppressed Sep 10 14:30:07 pandora pulseaudio[1412]: ratelimit.c: 208 events suppressed Sep 10 14:40:37 pandora pulseaudio[1412]: ratelimit.c: 197 events suppressed Sep 10 14:40:56 pandora pulseaudio[1412]: ratelimit.c: 176 events suppressed Sep 10 14:41:06 pandora pulseaudio[1412]: ratelimit.c: 204 events suppressed Sep 10 14:41:27 pandora pulseaudio[1412]: ratelimit.c: 203 events suppressed Sep 10 14:41:36 pandora pulseaudio[1412]: ratelimit.c: 203 events suppressed Sep 10 14:42:55 pandora pulseaudio[1412]: ratelimit.c: 199 events suppressed Sep 10 14:43:17 pandora pulseaudio[1412]: ratelimit.c: 269 events suppressed Sep 10 14:44:25 pandora pulseaudio[1412]: ratelimit.c: 176 events suppressed Sep 10 14:44:47 pandora pulseaudio[1412]: ratelimit.c: 174 events suppressed Sep 10 14:45:13 pandora pulseaudio[1412]: ratelimit.c: 195 events suppressed in /var/log/messages and a knotify4 eating all my cpu occurs. Have you found a solution ?
Hi Uday ! Appears that the bug wants a very specific scenario : a) Sound : HDA Intel b) Phonon Backend : gstreamer I don't know if, in this scenario, knotify4 loops awaiting something to happen, or it is invoked by a lot of notification request. Any case, i handled the problem by installing xine backend to phonon, and prefferring it. There is a bug in this new scenario too ( bug 737322 ). But it is less harmfull. Now, lets just wait that fedora guys have time to correct both.
(In reply to comment #3) > Hi, Uday ! > > I am with the same issue. > Is your sound hardware a HDA-INTEL like mine ? Actually, I had Intel ICH5 then. I now have a new machine, and this has HDA-Intel. I'm not sure if the bug still exists for me on this one -- it's a quad core and it's likely I won't notice if the scenario re-occurs. I never tried to find a solution when it existed - used to just kill pulseaudio and let it restart.
Hi lennart ! As this bug is assigned to you, maybe it helps. I don't understand phonon very much. But reading docs, i think that gstreamer is sendind a finished() signal in an erroneous condition. Hacking knotify4, you can see that : - When NotifyBySound::slotSoundFinished() is reached, a finished() signal was emmited ; - But finished() must be emmitted only when : a) the current media source has finished playing b) and the media queue() is empty ; - But queue is not empty when the slotSoundFinished() gets control. You can check this by : KDebug() << player->media->queue().size() ; just after the line : Player *player=d->playerObjects.take(id); inside the slotSoundFinished() method. Then, i'm asking myself why finished() was emmited if the queue is not empty. It sounds like a gstreamer backend bogus, i think. I hope that helps !
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping