Rockbox

Tasklist

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

Attached to Project: Rockbox
Opened by Dominik Riebeling (bluebrother) - Thursday, 14 April 2011, 22:25 GMT
Last edited by Thomas Martitz (kugel.) - Saturday, 04 June 2011, 20:41 GMT
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Operating System Android
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

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." (http://developer.android.com/reference/android/media/AudioTrack.html#getMinBufferSize(int, int, int))
This task depends upon

Closed by  Thomas Martitz (kugel.)
Saturday, 04 June 2011, 20:41 GMT
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed with r29961.
Comment by Thomas Martitz (kugel.) - Friday, 13 May 2011, 12:10 GMT
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.
Comment by Dominik Riebeling (bluebrother) - Saturday, 14 May 2011, 15:38 GMT
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.
Comment by Thomas Martitz (kugel.) - Saturday, 14 May 2011, 15:52 GMT
v2 doesn't seem to work, it makes things worse. v3 is a bigger rework which seems to work wonderfully for me.
Comment by Dominik Riebeling (bluebrother) - Sunday, 29 May 2011, 07:59 GMT
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.
Comment by Bryan Childs (GodEater) - Saturday, 04 June 2011, 20:37 GMT
v3 of the patch doesn't work for me either. Playback still stops rather randomly.

Loading...