Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
misterhh:
I just installed rockbox on my 4GB Clip+, rebooted into rockbox successfully, and played that block-breaking game. Then I selected Chopper, and I'm pretty sure it bricked. I cant turn it on, or connect it via USB. I know this is risky no-warranty software, but is there any way to force reset, etc?
edit: woah that was a scare, I held down the power button for 15 seconds then tried again and it turned on.
oxide:
--- Quote from: michaelc5047 on March 19, 2009, 11:48:49 PM ---There's been a bit of talk on the Sansa forums about a pitch issue on the Clip v2 and the Fuze v2, where playback of files with a sampling rate of 44.1KHz is 2% slower than it should be due to a clock problem. I personally have an 8GB Clip and a 4GB Clip (of the v1 variety) and have compared playback between the two, and noticed that the 8GB does play slightly more slowly.
--- End quote ---
The Clip v2 with the Sandisk 02.01.32 firmware does indeed play flat. In fact, it plays about 19 cents or 1/5 of a semitone flat. Enough to where it makes it so that if I play along on an in-tune guitar with a track that I know is in tune, it's out-of-tune with the Clip v2 with 02.01.32 firmware. Sandisk recently released new 02.01.35 firmware that fixes this pitch problem - the Clip v2 with 02.01.35 firmware now plays pretty much in tune.
HOWEVER! Doing the "play-along" test, I notice that the new Rockbox for the Clip v2 (thanks for all the hard work, guys!) also plays noticeably flat. I'm not sure if it's the exactly the same amount flat as the 02.01.32 firmware (someone with instrumentation will have to measure it), but it's noticeably flat.
bertrik:
Rockbox on AMS sansa (at least the clipv1, fuzev1 and e200v2) plays with a sample rate error of about 0.15%. It is possible to reduce this to 0.04% error by either 1) changing the entire clocking scheme of the AMS sansa or by 2) enabling a separate PLL for generation of the sample rate clock.
Option 1) is a bit controversial because it affects other sub-systems too (like maximum attainable CPU speed, display update rate, clocks for SD card access).
Option 2) takes a bit more power from the battery than we currently do, reducing runtime by approximately 2.5%
See the following patch for an implementation of option 2: http://www.rockbox.org/tracker/task/10906
The same trick can probably also be used to reduce the error on clipv2 players.
bYOndo:
--- Quote from: bertrik on March 26, 2010, 10:11:18 AM ---Rockbox on AMS sansa (at least the clipv1, fuzev1 and e200v2) plays with a sample rate error of about 0.15%. It is possible to reduce this to 0.04% error by either 1) changing the entire clocking scheme of the AMS sansa or by 2) enabling a separate PLL for generation of the sample rate clock.
Option 1) is a bit controversial because it affects other sub-systems too (like maximum attainable CPU speed, display update rate, clocks for SD card access).
Option 2) takes a bit more power from the battery than we currently do, reducing runtime by approximately 2.5%
See the following patch for an implementation of option 2: http://www.rockbox.org/tracker/task/10906
The same trick can probably also be used to reduce the error on clipv2 players.
--- End quote ---
And a permanent pitch modification? Maybe thru a string on config.cfg. It's less elegant and I don't know how much power it drains, I test a 440hz sample with a tuning fork next to the other ear and with a 101.1% of pitch correction it sounds perfectly in tune.
It changes both time&pitch so it's correct, isn'it?
just my 2 cents.
Massimo
FlynDice:
A bit more SD related info. I believe the controller we're dealing with is The Synopsys DesignWare® Mobile Storage Host Controller. Here is a link to a document with some info on page 119 - 120:
https://www.synopsys.com/dw/doc.php/doc/dwf/manuals/dw_frg.pdf
There is another 3 page .pdf available with a little bit more info but you need to register to access it. I did and there wasn't much more info there. They call it a datasheet but it's not the datasheet that would really help us. The one thing i did pick out of it though is that there are separate clocks to the card interface unit and the bus interface unit. I'm guessing CGU_MEMSTICK is going to the BIU and the CGU_BASE + 0x3C that is now renamed CGU_SDSLOT is going to the CIU. That would make sense with the frequencies we are running those at. CGU_IDE is still required as in the as3525v1 for reasons we still don't fully understand.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version