• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Music playback
  • Assigned To No-one
  • Operating System Android
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bluebrother - 2011-04-14
Last edited by kugel. - 2011-06-04

FS#12064 - Android: Possible fix for audio stopping on high CPU load

On my Android device (HTC Desire running HTC Sense) I experience audio stopping in some situations. The most annoying thing is that it’s not sufficient to simply stop and restart playback. It seems to be related to high CPU load. An easy way to trigger this is locking and unlocking the screen, the issue appears not on each cycle but often enough to be easily reproducable.

Increasing the size of the audio buffer made me not experience the problem anymore. I went with using 4* the minimum size as minimum, especially since the Android documentation says “Note that this size doesn’t guarantee a smooth playback under load, and higher values should be chosen according to the expected frequency at which the buffer will be refilled with additional data to play.” (, int, int))

Closed by  kugel.
2011-06-04 20:41
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Should be fixed with r29961.

Increasing the buffer introduces latency. This can especially be heard when when jumping through the track using the progressbar. Old data will be played back.

This patch has a slightly approach. It also increases the buffer, but but as much. It additionally refills earler, the buffer should be at least 50% full (~130ms) at all times. Lastly, on stop, all pending data is played back with muted volume so the latency isn’t hearable.

I’d still rather not increase the buffer, but lets see if it fixes the issue.

BTW: I lately also noticed audio dropouts when waking the phone, but only very short ones, and playback always recovers.

I’ve tried this but was able to reproduce the original issue (though only rarely).

- My device returns 12288 for getMinBufferSize(), therefore the v1 patch will make Rockbox use a buffer of 49152 Bytes.
- The v2 patch uses 48ki, so it’s the same value as the 4 * getMinBufferSize() in the v1 patch on my device. I don’t expect any difference in behaviour due to this.
- The v2 patch still the maximum out of 48ki or getMinBufferSize(). For phones where getMinBufferSize is 48ki or larger this would mean to use the minimum buffer size. This buffer size doesn’t guarantee smooth playback per Android documentation as I stated earlier. IMO the buffer size should be at least some amount bigger than the value returned by getMinBufferSize() to be on the safe side.
- I couldn’t reproduce the original issue with the v1 patch so the earlier refilling seems to make the behaviour worse. This doesn’t surprise me: from my current understanding the problem is caused by the onMarkerReached() callback getting missed. When refilling earlier this callback also comes earlier, and this in turn also increases the risk of missing it (since it comes more often).

I’d also prefer not increasing latency but the v2 patch makes the situation worse than the v1 patch on my device.

v2 doesn’t seem to work, it makes things worse. v3 is a bigger rework which seems to work wonderfully for me.

This task might be related to FS#12006

v3 of the patch doesn’t work for me, it makes things worse. This has been discussed in IRC but wasn’t documented here yet.

v3 of the patch doesn’t work for me either. Playback still stops rather randomly.


Available keyboard shortcuts


Task Details

Task Editing