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
Task Type Patches
Category Operating System/Drivers
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Release 3.4
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


There 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 ( ) 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).
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.
Comment by Bertrik Sikken (bertrik) - Sunday, 10 January 2010, 16:03 GMT
I think we have the following options for the clocking configuration (possibly more):

1) Run everything from a single PLL at 248 MHz (current situation)
* 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
* 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.
* 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
* 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
* 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)
* CPU processing power is less (running at 192 MHz instead of 248 MHz)
Comment by Bertrik Sikken (bertrik) - Wednesday, 13 January 2010, 19:05 GMT
Just to clarify, this patch is meant for people who want to experiment with using PLL B for audio (to measure current consumption for example).

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).
Comment by Bertrik Sikken (bertrik) - Thursday, 04 February 2010, 14:26 GMT
I did two battery benches on my clip v1, same mp3 album on repeat, one battery bench with plain SVN code and another with this patch.
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.
Comment by David Hall (Soap) - Thursday, 04 February 2010, 15:19 GMT
That runtime difference is consistent with the 3% penalty Sandisk NOW claims as their reason for not addressing the issue.
Comment by Tobias Diedrich (ranma) - Sunday, 28 March 2010, 14:17 GMT
The "just-noticeable difference" is for relative pitch though. So if you compare two players you could notice it. I'd assume it would only bother people with perfect pitch, maybe make it an option for people who'd rather have the 3% longer runtime?
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.
Comment by Matt M (Chesteta) - Tuesday, 18 May 2010, 12:56 GMT
would it be possible to enable this through a menu: so that users who need the little extra battery life can choose that route and those who prefer a higher sample rate accuracy (i am in this camp) can choose that?
Comment by Bertrik Sikken (bertrik) - Monday, 24 May 2010, 12:00 GMT
Yes, I think technically that would be possible.
Comment by Kevin Puetz (puetzk) - Saturday, 12 June 2010, 03:44 GMT
This is particularly annoying for recording; I won't claim I can hear even the current 0.15% error in pitch, but if I'm listening to a click track or accompaniment and recording myself, the two very drift very noticeably. If it's possible to switch at runtime, it might make sense to at least use the more accurate settings for recording. I don't expect it to line up well because I'm not much of a guitarist yet

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.
Comment by Michael Chicoine (mc2739) - Saturday, 12 June 2010, 03:59 GMT
@ Kevin

This patch only for the as3525 models (c200v2, clipv1, e200v2, fuzev1, m200v4) and will not work for the as3525v2 (clipv2, clip+, fuzev2)
Comment by Bertrik Sikken (bertrik) - Thursday, 24 June 2010, 10:59 GMT
The first patch (ams_pllb_for_audio.patch ) should now actually work with AMSv2 players too. For AMSv2 the activated PLLB clock has a setting of 192 MHz (reducing the error to 0.04% error).
Comment by Martin Sägmüller (dfkt) - Sunday, 27 June 2010, 10:33 GMT
Here are two battery benchmarks made on the Clip+, with and without PLLB enabled. I even got a few minutes more with PLLB enabled, compared to the default build.
Comment by Bertrik Sikken (bertrik) - Monday, 05 July 2010, 12:19 GMT
I did a similar battery benchmark on my clip+ (see SansaRuntime on the wiki), with and without PLLB enabled. I got 17h21m with plain SVN and 17h20m with PLLB enabled, iow 1 minute less runtime. If the PLL would really use an extra 2.5 mW, the runtime should have been about 40 minutes shorter.

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.
Comment by Matt M (Chesteta) - Monday, 16 August 2010, 13:36 GMT
Is this patch still 'possible' (being considered) for the AS3525 models? I have been hoping it will be committed :D
Comment by Michael Chicoine (mc2739) - Monday, 16 August 2010, 13:47 GMT Comment by Bertrik Sikken (bertrik) - Wednesday, 18 August 2010, 21:46 GMT
PLLB is now enabled for AMSv2 (clipv2, fuzev2, clip+) since SVN r27845. It may not be worth it to enable it on AMSv1 (clipv1, c200v2, e200v2, fuze v1), because the error isn't that big on those and enabling it *does* seem to decrease runtime.
Comment by Matt M (Chesteta) - Friday, 20 August 2010, 14:47 GMT
I would still appreciate an option on the V1 players to enable PLLB for a higher clock accuracy. I am willing to take the runtime hit, since I rarely listen to my music for 8+ hours at a time, running out of battery isn't much of an issue for me. I realize that enabling such an option would require work, how much work I am not sure (if I had experience programming I would do it myself, but I have no such experience). Respectfully, here is my vote for PLLB on AMSv1 :)