FS#10906 - Sansa AMS: use PLL B for higher audio sample rate accuracy
Attached to Project:
Rockbox
Opened by Bertrik Sikken (bertrik) - Sunday, 10 January 2010, 15:37 GMT
Last edited by Bertrik Sikken (bertrik) - Friday, 05 November 2010, 09:29 GMT
Opened by Bertrik Sikken (bertrik) - Sunday, 10 January 2010, 15:37 GMT
Last edited by Bertrik Sikken (bertrik) - Friday, 05 November 2010, 09:29 GMT
|
DetailsThere was some discussion recently on #rockbox about how accurate our audio sample rate is for AMS sansa targets, compared to the OF. This patch enables PLL B and uses it for the audio clock, resulting in higher sample rate accuracy (0.04% error). I already committed a change to make the audio clock selection more flexible, so the patch is really small.
In the current situation we use a 248 MHz PLL clock, which gives about 0.15% error. For reference, Wikipedia ( http://en.wikipedia.org/wiki/Pitch_%28music%29#Perception_of_pitch ) mentions a just-noticeable difference of 0.36 Hz at the 1-2kHz octave, which is 0.036% at 1 kHz. A disadvantage is that the now-enabled PLL consumes 2.5 mW typical (according to the AS3525 datasheet). 
ams_pllb_for_audio.patch
(0.6 KiB)
|
This task depends upon
Closed by Bertrik Sikken (bertrik)
Friday, 05 November 2010, 09:29 GMT
Reason for closing: Rejected
Additional comments about closing: An error of 0.15% is good enough for me. This patch did turn out to be useful in the end because it was *really* needed for the AMSv2 players.
Friday, 05 November 2010, 09:29 GMT
Reason for closing: Rejected
Additional comments about closing: An error of 0.15% is good enough for me. This patch did turn out to be useful in the end because it was *really* needed for the AMSv2 players.
1) Run everything from a single PLL at 248 MHz (current situation)
Advantages:
* maximum CPU power, so we try to get the most out of cpu-intensive codecs (like APE)
* no extra power consumed by an extra PLL
Disadvantages:
* high CPU clock requires a higher CPU voltage, resulting in increased battery current
* audio sample rate accuracy is OK (0.15% error), but not optimal (the error is several times larger than the just-noticeable pitch difference)
* we can't run USB from this clock (it needs 48 MHz which can't be derived from 248 MHz)
2) Run most things from one PLL at 248 MHz. Run audio and USB from another PLL at 384 MHz.
Advantages:
* maximum CPU power, so we try to get the most out of cpu-intensive codecs (like APE)
* more accurate sample rate (0.04% error)
* the USB clock can be derived from the same PLL as used for audio
Disadvantages
* high CPU clock requires a higher CPU voltage, resulting in increased battery current
* about 2.5mW extra power consumed by the extra PLL, I guess this amounts to about 0.8 mA battery current (assuming the 2.5 mW is generated from average 3.8V battery voltage at 80% efficiency)
3) Run everything from a single PLL at 384 MHz
Advantages:
* no extra power consumed by an extra PLL
* more accurate sample rate (0.04% error)
* the USB clock can be derived from the same PLL as used for audio
* the CPU voltage can be lowered, resulting in lower power consumption (there may be problems accessing sd cards at lower voltages for yet unknown reason)
Disadvantages:
* CPU processing power is less (running at 192 MHz instead of 248 MHz)
Here's another patch that does basically the same as the first one, but with a lower PLL frequency (288 MHz instead of 384 MHz), with the intent of lowering the power used by PLL B (2.5 mW typical according to the datasheet). The accuracy of the audio sample rate is still at 0.04% with this patch (compared to about 0.15% with SVN).
Plain SVN got a runtime of 8h16m and with this patch I got 8h03m. Percentage-wise this translates to 2.6% less runtime.
Calculated current (assuming a 350 mAh battery capacity) is 42.34 mA for plain SVN and 43.48 mA with this patch, or a 1.14 mA difference.
So in conclusion, I do see indeed a runtime reduction from the patch, but it's not dramatic.
Also this is just for 44100Hz (which is the common case of course), 48000Hz will likely need other settings (123MHz PLL, 6.150MHz mclk according to datasheet) for best accuracy.
I haven't tried this patch, because I have a Clip+, and it doesn't appear from the comments that these numbers would work on a v2. But the error I see if I just record the click track (@48kHz) and then line up the waveforms is 9488 samples out of 5631999, or 0.16%. So it seems like it's probably coming from the same cause.
This patch only for the as3525 models (c200v2, clipv1, e200v2, fuzev1, m200v4) and will not work for the as3525v2 (clipv2, clip+, fuzev2)
I checked the default PLLB setting to see if it is actually turned off in plain SVN (see attachment) and it does indeed appear to be turned off, bit 3, PLLB_PD (PLL B power down) is set.
For AMSv2, I think this has proven that runtime does not decrease when using PLLB.