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.

Comment 3 Andre Klapper 2009-12-31 18:05:17 UTC

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.

Comment 6 Andre Klapper 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/

*** 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?

Comment 9 Eero Tamminen 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.

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

Comment 13 Eero Tamminen 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?

(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 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.

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.

Comment 20 Andre Klapper 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).

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.