FS#9592 - AMS sansa sound playback

Attached to Project: Rockbox
Opened by Bertrik Sikken (bertrik) - Sunday, 30 November 2008, 20:39 GMT
Last edited by Rafaël Carré (funman) - Thursday, 04 December 2008, 22:28 GMT
Task Type Patches
Category Music playback
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Release 3.0
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


This 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.
This task depends upon

Closed by  Rafaël Carré (funman)
Thursday, 04 December 2008, 22:28 GMT
Reason for closing:  Accepted
Additional comments about closing:  r19342
Comment by Dominik Wenger (Domonoky) - Sunday, 30 November 2008, 22:03 GMT
I just got it working again on the sansa m200v4.
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.)
Comment by Rafaël Carré (funman) - Monday, 01 December 2008, 08:55 GMT
I have problems (CPU executing lock : I don't see the button light being enabled if I enable it just after modifying CGU_PERI), if I set the PLLA to 384MHz and set CGU_PERI to use the PLLA (even when setting cgu_peri to 24MHz)
I used this frequency to speed up SD transfers (according to test_codec mp3 decoding was not realtime when using 24MHz pclk)
Comment by Rafaël Carré (funman) - Monday, 01 December 2008, 09:21 GMT
More complete patch:

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)
Comment by Rafaël Carré (funman) - Tuesday, 02 December 2008, 17:27 GMT
With FS#9332 applied I have yet to experience a single crash, so the problems seem to come from buffering rather than from our code.

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)
Comment by Rafaël Carré (funman) - Tuesday, 02 December 2008, 19:18 GMT
* FS#9332 applied
* 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
Comment by Rafaël Carré (funman) - Wednesday, 03 December 2008, 18:28 GMT
*Actually put clock-target.h in the diff, and more frequencies defines
*Attempt at recording code (deadlocks when entering recording screen)
Comment by Rafaël Carré (funman) - Thursday, 04 December 2008, 01:45 GMT
* Correctly uses VIC_INT_EN_CLEAR instead of clearing the bits of VIC_INT_ENABLE
* Now entering the recording screen seems to black out LCD ? It might be due to the fact that i'm out of battery..
Comment by Rafaël Carré (funman) - Thursday, 04 December 2008, 21:11 GMT
* Committed some parts (clocks, dma)
* 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?) :/
Comment by Rafaël Carré (funman) - Thursday, 04 December 2008, 21:21 GMT
* Add buffering_flash.c to the diff
* Makes & conditional on MEMORYSIZE <= 2