maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Pulseaudio uses cpu constantly after a phone call.|
|Product:||[Maemo Official Platform] Multimedia||Reporter:||Toni Härkönen <toni.harkonen>|
|Status:||RESOLVED FIXED||QA Contact:||pulseaudio-bugs|
|Priority:||Low||CC:||adlorenz, andrea, andre_klapper, bogomips, bugelrex, eero.tamminen, egoshin, petechap, villekulo|
"pactl list" before killing tonegend
"pactl list" after killing tonegend
SOFTWARE VERSION: Maemo 5, 1.2009.42-11 EXACT STEPS LEADING TO PROBLEM: 1. Answer phone while the phone has been in locked state. 2. Have a couple of minutes conversation. 3. End the call. EXPECTED OUTCOME: No cpu usage for pulseaudio while the phone is not used. ACTUAL OUTCOME: Two pulseaudio processes stay permanently active at 1.4 - 4.0 percentage cpu rate. Behauviour observed with htop after noticing increased battery usage. Possibly prevents power saving modes activating. Activity stops only by rebooting the phone or killing the first of the two pulseaudio processes (other dies too). REPRODUCIBILITY: Reproduced only twice. Will look for more incidents. EXTRA SOFTWARE INSTALLED: Vpnc, vpnc-gui, rdesktop-cli, bounce evolution, leafpad, htop, scummvm, drnoksnes+wiicontrol, xournal, zoutube, vultures eye, liqtorch, documents to go, gpe file manager, omweather, gpxview, attitude, ati85, conboy OTHER COMMENTS: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:22.214.171.124) Gecko/20091102 Firefox/3.5.5
I haven't been able to reproduce the bug with different calling scenarios. Note: The second time the problem started, the phone had been rebooted and charged once with a n900's own charger. Uptime approximately four hours at this point. No any other use before the two phone calls: one not answered call, and one answered call, in this order. The duration of the answered call was approx. 15 minutes. I was able to spot this since I was expecting it after the first time, and have been checking the phone with htop after that. The time between the occurrences was approx. one week. Evidently this is a rare bug. Possibly this can happen with any sound activity with a mixer involved. Severity changed to a minor.
I've noticed this happening occasionally with my and my gf's N900. It drains battery quite fast but don't know how to reproduce it.
Thanks for reporting this. Confirming.
(In reply to comment #3) > Confirming. Any chance this is somehow related to bug #6365 ?
(In reply to comment #4) > (In reply to comment #3) > > > Confirming. > > Any chance this is somehow related to bug #6365 ? > I'm not sure. I noticed only pulseaudio-process itself doing this... Also I have had UI input-sounds disabled from the start. Of course it could be related through pulseaudio itself. Unfortunately at the time I noticed this problem I didn't have knowledge how to check the actual cpu rate. The constant CPU usage pulseaudio caused was only those 1 to 4 percent and not 100% (as it was with maemo-xinput-sounds). I'll look for this process if I ever see the problem again. As an update to this 6868 bug I've kept checking the htop often and I haven't got this problem not once, even if I'm using n900 constantly all the time. This seems to be a very rare bug indeed. This kind of confirms that it could be not related to calling behavior and be related to other pulseaudio bugs.
This has been fixed in package tone-generator 0.1.7+0m5 which is part of the internal build version 2009.51-13 (Note: 2009 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
*** Bug 8772 has been marked as a duplicate of this bug. ***
While we're waiting for the firmware, what actions can user's take to avoid this excess consumption? What actions in certain apps should be avoided?
(In reply to comment #8) > While we're waiting for the firmware, what actions can user's take to avoid > this excess consumption? What actions in certain apps should be avoided? The bug wasn't reproducible by the developers, but they made a potential fix to it into tonegend and it seems to have disappeared. The issue was speculated to be that if the stream flushing/draining failed the stream did not get destroyed. Tonegend did not seem to take any CPU time since the stream was already requested to be flushed/drained and therefore pulseaudio did not request tone buffers any more. From pulseaudio point of view this could happen when the call ends and the congestion tone is played. In this situation the internal buffering is changing at the same time the tonegend stream is drained/flushed. To verify whether your case is same, when the phenomenon happens, check whether 'pactl list' lists tonegend with a running stream. And to get rid of the battery consumption, do killall on tonegend or pulseaudio as root to get them restarted.
I live in an area with poor reception and often get cut off mid-conversation due to no signal. Today I noticed this tonegend problem after answering an incoming call and immediately getting cut off. I did a "pactl list" immediately before & after killing tonegend, the results of which I'll attach now (they diff quite nicely). I also attached quite a few diagnostics to bug 8772, which was my dupe of the same issue.
Created an attachment (id=2275) [details] "pactl list" before killing tonegend
Created an attachment (id=2276) [details] "pactl list" after killing tonegend
(In reply to comment #10) > I did a "pactl list" immediately before & after killing tonegend, the results > of which I'll attach now (they diff quite nicely). I also attached quite a few > diagnostics to bug 8772, which was my dupe of the same issue. Did killing tonegend fix the issue (and get tonegend restarted) of pulseaudio waking up constantly?
(In reply to comment #13) > Did killing tonegend fix the issue (and get tonegend restarted) of pulseaudio > waking up constantly? Not quite sure what you mean by "waking up constantly", but I think the answer is "yes". Killing/restarting tonegend solved the pulseaudio CPU usage problem without having to restart pulseaudio itself. After killing tonegend, CPU usage (as seen from "top") looked the same as a freshly-booted system. In bug 8772, I showed an strace of pulseaudio continually doing an ioctl on /dev/snd/pcmC0D0p while in the error condition (I assume it was playing silence to the audio device). Is this what you mean by "waking up"? I can do an strace on pulseaudio -after- killing tonegend if that would be useful.
(In reply to comment #14) > Killing/restarting tonegend solved the pulseaudio CPU usage problem without > having to restart pulseaudio itself. Then it should be the same issue what was fixed internally. Thanks! AFAIK that fix will not be in the next public release coming RSN (which fixes some connectivity related issues/regression from 51-1), but in the one after that.
I'd like to confirm that as with PeteC, the physical location where I got the bug has really bad reception. I didn't get cut off during the calls in effect but very possibly the 3g had changed to 2g and back both during and out of calling sessions, cutting out the calls technically speaking. This happens all the time in the room I'm working in. I've worked out the sweet spot in the room to prevent accelerated battery drain due to radios searching for coverage all the time, and I leave the phone there during the working hours. Maybe this is why I haven't seen the bug lately.
One detail more: I happen to carry n900 as a note making device into our server room many times a day, without the bug emerging. The place has no coverage at all, so definitely an ongoing call is required to activate the bug, not just cutting off the signal in general.
Just my three cents: I wasn't able to recreate the issue after a call (whether I used or not tone buttons during the call) but killing tonegend fixes pulseaudio floating at 1-3% of CPU time. Looking forward to see this issue fixed in future releases.
Got the bug again. 'Killall tonegend' fixed the situation for me too.
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
Got a problem, noticed it via unusual battery discharge. I fixed it via 'killall pulseaudio' (!). ADDITIONAL INFO: in my case I was able to run powertop. It shows that 'per' and 'core' are ON 100% and top IRQ was 'DMA' and only next - 'i2c_omap'. However, 'top' doesn't show 100% CPU load.