• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2010-01-10
Last edited by bertrik - 2010-11-05

FS#10906 - Sansa AMS: use PLL B for higher audio sample rate accuracy

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

Closed by  bertrik
2010-11-05 09:29
Reason for closing:  Rejected
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

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.

I think we have the following options for the clocking configuration (possibly more):

1) Run everything from a single PLL at 248 MHz (current
* maximum CPU power, so we try to get the most out of cpu-intensive codecs (like
no extra power consumed by an extra
* high CPU clock requires a higher CPU voltage, resulting in increased battery
audio sample rate accuracy is OK (0.15% error), but not optimal (the error is several times larger than the just-noticeable pitch
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
* maximum CPU power, so we try to get the most out of cpu-intensive codecs (like
more accurate sample rate (0.04%
the USB clock can be derived from the same PLL as used for
* high CPU clock requires a higher CPU voltage, resulting in increased battery
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
* no extra power consumed by an extra
more accurate sample rate (0.04%
the USB clock can be derived from the same PLL as used for
the CPU voltage can be lowered, resulting in lower power consumption (there may be problems accessing sd cards at lower voltages for yet unknown
* CPU processing power is less (running at 192 MHz instead of 248 MHz)

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

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
SVN got a runtime of 8h16m and with this patch I got 8h03m. Percentage-wise this translates to 2.6% less
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.

Soap commented on 2010-02-04 15:19

That runtime difference is consistent with the 3% penalty Sandisk NOW claims as their reason for not addressing the issue.

ranma commented on 2010-03-28 14:17

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

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?

Yes, I think technically that would be possible.

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.

@ Kevin

This patch only for the as3525 models (c200v2, clipv1, e200v2, fuzev1, m200v4) and will not work for the as3525v2 (clipv2, clip+, fuzev2)

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

dfkt commented on 2010-06-27 10:33

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.

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.

Is this patch still ‘possible’ (being considered) for the AS3525 models? I have been hoping it will be committed :D

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.

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


Available keyboard shortcuts


Task Details

Task Editing