• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Music playback
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.0
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2008-11-30
Last edited by funman - 2008-12-04

FS#9592 - AMS sansa sound playback

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.

Closed by  funman
2008-12-04 22:28
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407


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.)

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)

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 0×48000 bytes for the codec in iram and 0×8000 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)

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)

* 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

*Actually put clock-target.h in the diff, and more frequencies defines
*Attempt at recording code (deadlocks when entering recording screen)

* 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..

* 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?) :/

* Add buffering_flash.c to the diff
* Makes & conditional on MEMORYSIZE ⇐ 2


Available keyboard shortcuts


Task Details

Task Editing