This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9592 - AMS sansa sound playback
Attached to Project:
Rockbox
Opened by Bertrik Sikken (bertrik) - Sunday, 30 November 2008, 21:39 GMT+1
Last edited by Rafaël Carré (funman) - Thursday, 04 December 2008, 23:28 GMT+1
Opened by Bertrik Sikken (bertrik) - Sunday, 30 November 2008, 21:39 GMT+1
Last edited by Rafaël Carré (funman) - Thursday, 04 December 2008, 23:28 GMT+1
|
DetailsThis patch adds basic sound playback to ams sansa targets. Playback may lock up after some time, beware.
This is basically the ams sansa playback patch that funman posted to IRC, with only minor cleanup by me. 
ams_sansa_playback_1.patch
(10.8 KiB)
apps/plugins/plugin.lds | 16 +++++- apps/plugins/SOURCES | 1 apps/playback.c | 5 +- firmware/export/config-clip.h | 4 - firmware/target/arm/as3525/pcm-as3525.c | 70 ++++++++++++++++++++++++++--- firmware/target/arm/as3525/dma-pl081.c | 8 ++- firmware/target/arm/as3525/system-as3525.c | 2 firmware/target/arm/as3525/app.lds | 23 +++++---- firmware/target/arm/as3525/dma-target.h | 2 firmware/target/arm/as3525/ata_sd_as3525.c | 10 ++-- firmware/drivers/audio/as3514.c | 3 + 11 files changed, 115 insertions(+), 29 deletions(-) |
This task depends upon
Closed by Rafaël Carré (funman)
Thursday, 04 December 2008, 23:28 GMT+1
Reason for closing: Accepted
Additional comments about closing: r19342
Thursday, 04 December 2008, 23:28 GMT+1
Reason for closing: Accepted
Additional comments about closing: r19342
The Key was a svn bootloader with a patched main-build. So i think the new Frequency Setting is causing my problem. ( shutdowns while trying to play something.)
I used this frequency to speed up SD transfers (according to test_codec mp3 decoding was not realtime when using 24MHz pclk)
implements missing functions in pcm-as3525.c
check the 2 dma channels in the interrupt handler (both can be active at the same time)
modify m200v4 config
allocates 0x48000 bytes for the codec in iram and 0x8000 for the main binary (nothing for plugins)
Still noticing spurious deadlocks (the PCM buffer continues to be played shortly after the deadlock, probably until the current DMA transfer is finished)
If this is the case (more testing will tell) then we can commit this.
But prior we should solve our problem of clocks:
I think that we want to use a high frequency pclk, because this is the clock controlling memory; rather than using a low frequency for power saving.
See my previous comment, and the fact that the setting in this patch doesn't work on m200v4.
I'll check what pclk the OF uses when I recover access to my laptop (and disassembly files)
* Use defines in clock-target.h to control clock speeds so we don't forget one
* Use 41MHz pclk and 82MHz clock for external memory
*Attempt at recording code (deadlocks when entering recording screen)
* Now entering the recording screen seems to black out LCD ? It might be due to the fact that i'm out of battery..
* Removed recording code
TODO: cleanup linker scripts, and let models with more memory put the codec buffer into SDRAM
Note that SVN has now a bug which makes using sound impossible (a unhandled IRQ 0 == WATCHDOG happens?) :/
* Makes app.lds & plugin.lds conditional on MEMORYSIZE <= 2