Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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 Sikken - 2008-11-30
Last edited by Rafaël Carré - 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  Rafaël Carré
2008-12-04 22:28
Reason for closing:  Accepted
Additional comments about closing:  

r19342

Dominik Wenger commented on 2008-11-30 22:03

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

Rafaël Carré commented on 2008-12-01 08:55

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)

Rafaël Carré commented on 2008-12-01 09:21

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)

Rafaël Carré commented on 2008-12-02 17:27

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)

Rafaël Carré commented on 2008-12-02 19:18

* 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

Rafaël Carré commented on 2008-12-03 18:28

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

Rafaël Carré commented on 2008-12-04 01:45

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

Rafaël Carré commented on 2008-12-04 21:11

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

Rafaël Carré commented on 2008-12-04 21:21

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

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing