607200 - Extremely high CPU use when playing HTML 5 audio on Maemo 5/N900

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Matthew Gregan [:kinetik]]

Spinning this off from bug 601542 comment 24 through 27.

Further details:
Using a standalone test app that does nothing but submit audio as fast as possible, relying on snd_pcm_writei blocking for timing.  It writes period_size bytes each time, which should be ideal.

The first column is milliseconds spent in snd_pcm_writei, the second column is the number of frames written (which should equal the period size).

10ms:
  buffer_size  : 480
  period_size  : 120
1 120
1 120
9 120
0 -32
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured


100ms:
  buffer_size  : 4800
  period_size  : 1200
1 1200
1 1200
4 1200
106 -32
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured


200ms:
  buffer_size  : 9600
  period_size  : 2400
1 2400
1 2400
251 2400
100 -32
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured


250ms (our default):
  buffer_size  : 12000
  period_size  : 3000
0 3000
1 3000
5 3000
254 -32
ALSA lib pcm.c:7234:(snd_pcm_recover) underrun occured


300ms:
  buffer_size  : 14400
  period_size  : 3600
1 3600
1 3600
1 3600
257 3600


500ms (our old default):
  buffer_size  : 24000
  period_size  : 6000
0 6000
260 6000
0 6000
260 6000


1000ms:
  buffer_size  : 48000
  period_size  : 12000
259 12000
260 12000
260 12000
260 12000


So below 300ms, this bug seems to occur for every tested setting.  The configuration appears to have 4 fragments 1/4 the buffer size each (as expected), but once the buffer has filled the next write blocks for the entire buffer length, resulting in an underrun.

Running the same test on my Fedora 13 desktop, the writes never block for more than 1/4 to 1/2 of the buffer size, so there's always time to refill before an underrun can occur.

The changes in the PulseAudio ALSA plugin between the version on the N900 and my desktop are fairly small, and none of them obviously change this behaviour.  That leads me to assume that the PulseAudio server's behaviour has changed and this bug has been fixed.  The number of changes between the two versions of PA is large, so it's not worth spending the time tracking this down further.

So let's go with the patch I attached to bug 601542 as a workaround.  My plan for post Firefox 4 is to replace the current Linux audio code with a PulseAudio client version, which should make it much easier to understand these types of interactions in the future.

Comment 1

[Matthew Gregan [:kinetik]]

Attachment: patch v0

Referring to comment 24 and 25 of bug 526411, as well as comment 76: with the new decoder implementation, we can decode video and audio separately and therefore ensure we decode enough audio ahead that we fill the OS buffers and start playback.  The logic in nsBuiltinDecoderStateMachine::AudioLoop tries to keep 1-2s of audio queued in the backend.  As long as this exceeds the prebuf size for ALSA/PA (as determined by the latency requested in snd_pcm_set_params), we won't regress bug 526411.

Mochitests pass on my machine and audio plays smoothly with low CPU on the N900.   I've tested this against the testcase in bug 526411 comment 59 as well and it seems to work fine (I don't hit that bug, but I do eventually hit bug 573924 both with and without the patch).

Comment 2

[Matthew Gregan [:kinetik]]

http://hg.mozilla.org/mozilla-central/rev/03ecc29fc193