Description of problem: After updating to pulseaudio-0.9.21-4.fc12, pulseaudio jumps to 100% CPU usage when sound is played. Going back to pulseaudio-0.9.21-2.fc12 fixes the issue. Stracing the 100% CPU process yields a loop in 'ppoll' (which goes about as far as my limited debugging capacities permit) : [pid 11783] <... ioctl resumed> , 0x7f1bf8f11c50) = 0 [pid 11776] <... ppoll resumed> ) = 1 ([{fd=27, revents=POLLHUP}]) [pid 11783] ppoll([{fd=17, events=POLLIN}, {fd=18, events=POLLIN}, {fd=35, events=POLLOUT|POLLERR|POLLNVAL}], 3, {0, 119632000}, NULL, 8 <unfinished ...> [pid 11776] ppoll([{fd=4, events=POLLIN}, {fd=27, events=0}, {fd=21, events=POLLIN}, {fd=20, events=POLLIN}, {fd=34, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=22, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=32, events=POLLIN}, {fd=31, events=POLLIN}, {fd=30, events=POLLIN|POLLERR|POLLHUP}, {fd=30, events=0}, {fd=23, events=POLLIN}, {fd=26, events=POLLIN}, {fd=16, events=POLLIN}, {fd=19, events=POLLIN}, {fd=15, events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 23, NULL, NULL, 8) = 1 ([{fd=27, revents=POLLHUP}]) [pid 11776] ppoll([{fd=4, events=POLLIN}, {fd=27, events=0}, {fd=21, events=POLLIN}, {fd=20, events=POLLIN}, {fd=34, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=22, events=POLLIN}, {fd=29, events=POLLIN}, {fd=33, events=POLLIN}, {fd=32, events=POLLIN}, {fd=31, events=POLLIN}, {fd=30, events=POLLIN|POLLERR|POLLHUP}, {fd=30, events=0}, {fd=23, events=POLLIN}, {fd=26, events=POLLIN}, {fd=16, events=POLLIN}, {fd=19, events=POLLIN}, {fd=15, events=POLLIN|POLLERR|POLLHUP}, {fd=15, events=0}, {fd=14, events=POLLIN}, {fd=13, events=POLLIN}, {fd=6, events=POLLIN}], 23, NULL, NULL, 8) = 1 ([{fd=27, revents=POLLHUP}]) [... etc ...]
Strange : the above was reproducible on a Dell i1720 (deleting ~/.pulse between trials), but appearantly on first sight does not occur on an ASUS EeePC 901 ... i1720 : 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) EeePC901 : Intel 82801G (ICH7)
Hmm, do you think you could do a git bisect run for me? Youd need to know your way around with compiling PA and git.
(if someone is able and willing to do the git bisect, what I am interested in is the path between v0.9.21..stable-queue in git://git.0pointer.de/pulseaudio.git)
*** Bug 558981 has been marked as a duplicate of this bug. ***
*** Bug 558656 has been marked as a duplicate of this bug. ***
Well, I'm away for some days. I'llget back to you when I'm back (recompiling PA is no problem, but I am a complete novice with git).
Add me to the list - strace looks exactly the same as the reporter and have just downgraded to pulseaudio-0.9.21-2.fc12. Unfortunately not familiar with compiling PA and git to bisect unless you can give some pointers...
*** Bug 564383 has been marked as a duplicate of this bug. ***
*** Bug 564525 has been marked as a duplicate of this bug. ***
Over here I see the same happen. Hardware used: 00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
*** Bug 565883 has been marked as a duplicate of this bug. ***
I have tried for multiple hours to reproduce this issue, but was unable to. I have sent myself gazillions of emails to trigger the new mail sounds but things never behaved badly. So I am really not sure what is going on here. Can anybody reduce this to a simple reproducible test case that I can reliably run here? Anyway, as an educated guess here's what I believe what could be happening here: 1) PA suspends (i.e. closes) the audio devices because it is idle 2) some legacy app (Flash?) opens the audio device bypassing PA, and can do so because the device is not used because PA is idle. 3) Thunderbird wants to play audio due to an incoming mail, and plays audio to PA. Now, PA tries to unsuspend (i.e. reopen) the audio devices, but cannot because the legacy app still blocks the device. PA will hence leave the devices suspended. Because Thunderbird didn't set the PA_STREAM_FAIL_ON_SUSPEND flag when playing the stream it will be queued up. This happens a couple of times. So a more and more streams are queued up. 4) Eventually the limit of concurrent streams in PA is reached (defined to 32 right now). Now clients are refused. Some client doesn't accept that, and requests a new connection when the first try fails. 5) We enter a busy loop due to that, you'll see 100% CPU used. Now, this is just a guess. To verify these issues, I'd like to ask you all to reproduce the issue locally and then run "pacmd ls" and attach the output here. Also, at the same time please run "fuser -v /dev/dsp* /dev/snd/*" and attach it here too. Finally, if you could run PA in debug mode (Pass -vvvvv while running it in a terminal, and set autospawn=no in ~/pulse/client.conf) and paste the output here that is generated when you enter this lockup I should be able to track this down. The reason I came up with this guess is because I can make thunderbird freeze by issuing "pacmd suspend 1" (which is a manual hard suspend of PA's device access) and then wait for the new mail sound. So one lesson here is that Thunderbird needs to be fixed not to queue up event sounds, but instead use PA_STREAM_FAIL_ON_SUSPEND -- which libcanberra, the event sound library they should be using, of course does.
Hmm, the reason why thundebird isn't setting PA_STREAM_FAIL_ON_SUSPEND seems to be that they still use the legacy esd protocol instead of pulseaudio's native protocol. Here's another thing I'd like you to ask to test: please edit /etc/pulse/default.pa and comment the "load-module module-esound-protocol-unix" line. Now restart PA and try to reproduce the issue. Does this fix things for you?
$ fuser -v /dev/dsp* /dev/snd/* Cannot stat /dev/dsp*: No such file or directory Cannot stat /dev/dsp*: No such file or directory USER PID ACCESS COMMAND /dev/snd/controlC0: udo 14822 F.... pulseaudio /dev/snd/pcmC0D0p: udo 14822 F...m pulseaudio
Created attachment 394859 [details] pacmd ls output pacmd ls output
Created attachment 394860 [details] pulseaudio -vvvvv
Created attachment 394865 [details] another -vvvv run, more v's used
Did we provide enough of the right info/logging? Do we need to provide more data?
Created attachment 394898 [details] another pacmd capture
Created attachment 394899 [details] another fuser capture
Created attachment 394900 [details] another pulseaudio capture
Added my various captures. One thing that was noted in my original bug report is that this ONLY happens when I use a non-system sound for new mail. The little beep causes no problem (because of the length it plays? because it's not a .wav?) but use of the wav file results in the 100% CPU every time. Playing the wav any other way works fine - it's only in T'bird.
I think I can confirm comment 23; I am using the notify.wav from a software vendor in Redmond, WA, USA.
Well, mine's a cow so we can rule out dark forces... ;)
Could someone try to do what I suggested in comment 13 and see if that fixes the problem?
I think I would be able to track this down if someone could send me a full strace -f of PA when this happens. The small strace excerpt in the original post shows that that poll() returns POLLHUP on fd 27 which is not processed. Now the problem is, what is fd 27? the strace should allow us to figure that out by going backwards and looking for where it got created. A full strace will be substantial in size, so better don't attach it here, but upload it somewhere or mail it to me.
Sorry, I did try the suggestion in comment 13 and found it made no difference at all. I forgot to post a reply.
Created attachment 395194 [details] compressed strace output full strace output
Hopefully the attachment I just put up in tar.gz format is what you're after.
Do you have enough strace data etc etc to analyse the root cause? I hope you understand that most people with a 'modern' distro might be affected by this bug, because these ship pulseaudio, especially if they use a less dull signal for their incoming mail. They will have at least one core wasting all cycles to this problematic issue. That means a LOT of wasted power!! (100% CPU versus typically ~20% or so?) So please HURRY fixing this bug. Please.
This bug seems to happen to me several times a day. I'm not sure of exactly how to reproduce it but it seems to happen to me fairly often when I have two firefox windows open on two different monitors. If I'm playing some flash video on one and then open a new window on my second monitor to browse other websites it appears to be happen more frequently. It may be triggered by navigating to a web page on the second instance of firefox that also uses flash.
(In reply to comment #32) So you mean no thunderbird connection at all? That would mean a second way to trigger this bug. Can you supply a strace as asked in comment 27?
comment 13 fix of commenting out the esound line makes no difference. However, I may be seeing a combination of another problem as well. Sometimes there is a complete system lock-up but sometimes it may just be that the keyboard is stuck in some spots. When the system slowed right, I closed all my open programs, I tried to open a terminal to type strace but the terminal just sits there and won't accept any keyboard input. The caps lock key doesn't toggle the light at all. Since that happens to be how I usually check if the system is locked up I may not have noticed other times that I can launch other programs. I restarted Firefox just now and the keyboard works here. CAPS LOCK works here (even though the light doesn't change). However, it still doesn't work in the terminal. Also, the terminal won't close. This is the same thing pulse audio does if I try to restart the system. It warns me that PulseAudio is not responding. If I quit anyway then in the black shutdown sequence it hangs at "Sending processes the TERM signal..."
Re comment 33: this is not a Thunderbird issue. This is 100% reproducible for me in Firefox, see dupe bug 564525.
(In reply to comment #34) > comment 13 fix of commenting out the esound line makes no difference. Did you restart PA and have you verified that the esound modules are not loaded with "pacmd list-modules"? I now managed to reproduce this issue with a simple "esdplay". Seems the fix for bug 553607 broke this. And as mentioned, an easy temporary workaround to fix this is to disable the esd support in PA.
Fixed in this commit: http://git.0pointer.de/?p=pulseaudio.git;a=patch;h=30f28ebf3619a86b49009e8dbce154233f597dbb Will upload a new version of PA shortly.
pulseaudio-0.9.21-6.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/pulseaudio-0.9.21-6.fc13
pulseaudio-0.9.21-5.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/pulseaudio-0.9.21-5.fc12
Even though we did not get a chance to confirm the fixing of the bug before you closed it (!!), I want to confirm it appears to be fixed.
Well, please understand that I like to keep my list of open bugs minimal. If I believe I fixed a bug I close it. If it turns out that my fix was incorrect or incomplete then there's nothing that would stop you from reopening it then.
pulseaudio-0.9.21-6.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
pulseaudio-0.9.21-5.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.