Rockbox

I did some tests in the buffering screen with the update frequency set to 10 seconds while playing an Ogg file on my e200v1 with back light forced on and the player running off USB power.

SVNr20007: CPU load varies between 37.4-37.8 MHz and settled to 37.7 after 4 minutes.
 FS#9910 : CPU load varied less, and settled to 37.0 MHz.

Both tests were the same track, begun measuring about 30 second in to avoid buffering.

From time to time there are short (0.5s) breaks in playback. It happened a few times during 6 hour listening on H10.

Here is a new version I would consider nearly committable. It breaks up the buffers to get around the problem of reading the status register clearing the interrupt from outside the handler.

e260, using r20017, MP3 ~200kb VBR with tone controls on (I use them), same track, Hold ON to force backlight (thus screen updates) off:
1.8% (30.9 MHz) without  FS#9910  0.6% (30.3 MHz) with  FS#9910 

The H10 troubles may be from the constant rapid boost/unboost cycles that were present before r20017. I’m not sure they’re because of this patch as much as an existing issue manifested by it. Any induced breaks would be very short with SVN (1/3675 seconds) but since buffers are about 1/2 second, the gap would be quite noticeable with the patch. If they persist with the newer patch, they’ll now be about 1/256 seconds.

   pp502x-DMA-audio-playback-v2.... (18.4 KiB)

So far I’ve been listening to H10 for 5 or so hours without a dropout.

One other benefit here is greater PCM reserve on the audio FIFOs both from being able to have a higher watermark level to being able to complete a block of audio without having to leave a final one or two samples for a final interrupt. The current SVN method can leave the FIFO nearly empty which requires a rapid series of interrupts to finish the current block and start the next. In short, it greatly reduces the chance of IIS FIFO underruns besides giving a few cycles back better used for other things (including no audio-related cache activity during transfers, just writeback at callback time).

The problem I mentioned concern r20016. I’ll check the most recent revision and let you know.

I finally listened to my H10 20GB for about 6.5 hours on r20017 before giving up so that seems like a “test passed” for my unit. codec_set_elapsed_callback called pcm_get_bytes_waiting which was some of the problematic code that could botch things up but that is gone in v2 of the patch.

No problems here either.
I probably haven’t tested is as thoroughly as MikeS, but so far I haven’t run into any problems on my e200 with the v2 patch applied (played around a lot with general playback quite a lot).

After over 6 hour listening test I can say revision 20029 with version 2 patch works fine.