Bug 6868 - (int-148030) Pulseaudio uses cpu constantly after a phone call.
(int-148030)
: Pulseaudio uses cpu constantly after a phone call.
Status: RESOLVED FIXED
Product: Multimedia
Pulseaudio
: 5.0/(2.2009.51-1)
: N900 Maemo
: Low minor with 8 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: pulseaudio-bugs
:
: use-time
:
:
  Show dependency tree
 
Reported: 2009-12-11 20:49 UTC by Toni Härkönen
Modified: 2010-04-27 04:22 UTC (History)
9 users (show)

See Also:


Attachments
"pactl list" before killing tonegend (33.96 KB, text/plain)
2010-02-12 01:02 UTC, PeteC
Details
"pactl list" after killing tonegend (33.11 KB, text/plain)
2010-02-12 01:02 UTC, PeteC
Details


Note

You need to log in before you can comment on or make changes to this bug.


Description Toni Härkönen (reporter) 2009-12-11 20:49:30 UTC
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:1.9.1.5)
Gecko/20091102 Firefox/3.5.5
Comment 1 Toni Härkönen (reporter) 2009-12-12 17:24:52 UTC
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.
Comment 2 Ville Kulo 2009-12-28 14:34:23 UTC
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.
Comment 3 Andre Klapper maemo.org 2009-12-31 18:05:17 UTC
Thanks for reporting this.
Confirming.
Comment 4 Andrea Borgia 2009-12-31 19:29:51 UTC
(In reply to comment #3)

> Confirming.

Any chance this is somehow related to bug #6365 ?
Comment 5 Toni Härkönen (reporter) 2010-01-01 13:50:25 UTC
(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.
Comment 6 Andre Klapper maemo.org 2010-01-07 15:11:02 UTC
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/
Comment 7 PeteC 2010-02-02 14:45:17 UTC
*** Bug 8772 has been marked as a duplicate of this bug. ***
Comment 8 bugelrex 2010-02-11 00:55:09 UTC
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?
Comment 9 Eero Tamminen nokia 2010-02-11 11:28:38 UTC
(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.
Comment 10 PeteC 2010-02-12 01:00:24 UTC
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.
Comment 11 PeteC 2010-02-12 01:02:14 UTC
Created an attachment (id=2275) [details]
"pactl list" before killing tonegend
Comment 12 PeteC 2010-02-12 01:02:51 UTC
Created an attachment (id=2276) [details]
"pactl list" after killing tonegend
Comment 13 Eero Tamminen nokia 2010-02-12 10:41:58 UTC
(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?
Comment 14 PeteC 2010-02-12 12:45:55 UTC
(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.
Comment 15 Eero Tamminen nokia 2010-02-12 14:24:26 UTC
(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.
Comment 16 Toni Härkönen (reporter) 2010-02-13 08:28:50 UTC
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.
Comment 17 Toni Härkönen (reporter) 2010-02-13 08:39:41 UTC
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.
Comment 18 Dawid Lorenz 2010-02-24 12:57:40 UTC
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.
Comment 19 Toni Härkönen (reporter) 2010-02-24 20:02:22 UTC
Got the bug again. 'Killall tonegend' fixed the situation for me too.
Comment 20 Andre Klapper maemo.org 2010-03-15 20:55:38 UTC
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).
Comment 21 egoshin 2010-04-27 04:22:01 UTC
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.