Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#9910 - Use DMA engine for audio playback on PP502x targets

Attached to Project: Rockbox
Opened by Michael Sevakis (MikeS) - Sunday, 15 February 2009, 06:00 GMT+2
Last edited by Michael Sevakis (MikeS) - Thursday, 19 February 2009, 21:48 GMT+2
Task Type Patches
Category Drivers
Status Closed
Assigned To Michael Sevakis (MikeS)
Player Type PortalPlayer-based
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

Changes playback on PP502x based targets to use DMA. More battery life is possible since not as many CPU cycles will be needed in order to transfer audio to the codec and a reduction is buffering time is possible too. Needs testing just to make sure everything works alright for all relevant targets and if possible I'm curious about battery benches, etc.

No recording work with the DMA engine is done here. If playback is reliable, it's likely just about the details for that.

It appears on my e260 there is a couple megahertz reduction in boost compared to the same tracks doing it the old way.
   pp502x-DMA-audio-playback.diff (17.1 KiB) 
 firmware/export/pp5020.h     |   90 ++++++++++++++++++++
 firmware/target/arm/i2s-pp.c |    4 
 firmware/target/arm/pcm-pp.c |  192 +++++++++++++++++++++++++++++++++++++------
 3 files changed, 258 insertions(+), 28 deletions(-)

This task depends upon

Closed by  Michael Sevakis (MikeS)
Thursday, 19 February 2009, 21:48 GMT+2
Reason for closing:  Accepted
Additional comments about closing:  Added to r20053 with some changes. Seems ok enough so I'll keep an eye on things with it "out there" now.
Comment by MichaelGiacomelli (saratoga) - Sunday, 15 February 2009, 07:27 GMT+2
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.
Comment by Przemysław Hołubowski (p.h.) - Monday, 16 February 2009, 17:05 GMT+2
From time to time there are short (0.5s) breaks in playback. It happened a few times during 6 hour listening on H10.
Comment by Michael Sevakis (MikeS) - Monday, 16 February 2009, 20:22 GMT+2
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.diff (18.4 KiB) 
 firmware/export/pp5020.h            |   95 ++++++++++++++++
 firmware/target/arm/i2s-pp.c        |    4 
 firmware/target/arm/system-pp502x.c |    1 
 firmware/target/arm/pcm-pp.c        |  205 ++++++++++++++++++++++++++++++------
 4 files changed, 269 insertions(+), 36 deletions(-)

Comment by Michael Sevakis (MikeS) - Tuesday, 17 February 2009, 02:39 GMT+2
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).
Comment by Przemysław Hołubowski (p.h.) - Tuesday, 17 February 2009, 10:04 GMT+2
The problem I mentioned concern r20016. I'll check the most recent revision and let you know.
Comment by Michael Sevakis (MikeS) - Tuesday, 17 February 2009, 17:21 GMT+2
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.
Comment by Bertrik Sikken (bertrik) - Tuesday, 17 February 2009, 17:30 GMT+2
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).
Comment by Przemysław Hołubowski (p.h.) - Tuesday, 17 February 2009, 23:30 GMT+2
After over 6 hour listening test I can say revision 20029 with version 2 patch works fine.

Loading...