dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Sansa e280v2 clock drift

Re: Sansa e280v2 clock drift

From: Andrew Skretvedt via rockbox <>
Date: Sat, 21 Nov 2015 02:34:43 +0000

On 2015-Nov-05 15:07, Bernhard M. via rockbox wrote:
> I believe that's a problem alla Sansa-player share. My Clip+ and Clip
> Zip never showed the right time. There always was and is a big diff
> to the time shown on the radio controlled watch after only some
> days.
> Greetings
> Bernhard

I agree. -10 minutes/day is way way WAY larger an offset than I've ever
noticed. It suggests the possibility that perhaps the way the device
keeps time is making it vulnerable to loosing ticks off its RTC clock
oscillator, or something similar (software/firmware issues), as opposed
to that oscillator being fundamentally set to the wrong frequency.

From my experience with my Sansa Clip Zip, it's possible oscillator
accuracy in general was never a point of scrutiny for the design
engineers. SanDisk even had to release their own firmware tweaks when
users complained of pitch offsets.

In testing and measuring my own device, the real-time clock has an
offset of about -20 seconds/month. Not terrible, but I'm a stickler for
accurate timepieces ;-).

But I also noticed that all the sample clocks for the recording mode
were out too. Each record sample rate setting was out by a different
amount, some were fast and some were slow, sometimes by a large amount.
Typical consumer-grade PC soundcards have sample clock error in the
range of a few tens of parts-per-million. But the smallest offset I
measured (at 44.1 kHz setting), was +404 ppm, an order of magnitude worse!

The worst offset in my device was 48 kHz, which was -23,407 ppm off
(i.e. the actual clock rate achieved as 46,876 Hz), and the next worst
was 32 kHz, which was +19,032 ppm off (i.e. the actual clock was 32,609
Hz). That's truly atrocious! Absolutely terrible! And what this means is
that the indicated elapsed time on recordings is not at all going to
match real time. You'll be off perhaps by tens of seconds or even nearly
a minute after every hour of recording.

If you use the device for any semi-serious work, like remote-mics for a
video, you'll need to measure these offsets so you can compensate them
out of the raw recorded audio in post (I use SoX's speed effect for
this). Otherwise, you'll never get audio that stays in sync. (This
device is not really suitable for this use...they appear to have forgot
proper de-coupling capacitors on the ADCs, as all the recorded audio
I've made has a DC offset that varies predictably with mic gain
setting...another sign of loose attention to detail in the electronic

I haven't measured the playback sample clocks, so I do not know if they
are similarly as bad, but given the experience of users and Sansa's
firmware tweaks to compensate "off-pitch" complaints, they may be way
out also. (If they are out, and by the same amounts as the record
clocks, this will obviously produce the effect that audio recorded on
the device will not be accurate in terms of displayed elapsed time, but
will be sonically accurate, and would also mean that if you are really
pitch sensitive, and detect a pitch shift playing audio from a foreign
source, you could reprocess it yourself to adjust it to the timebase
your player achieves, again to get sonic accuracy back.)

Sadly, from an end-user perspective, there's likely little which can be
done. From a firmware perspective, the opportunities for compensation
are also probably rather limited, and probably ought only be considered
if a sizable sample of a given model are all indicating the same offsets.

Try another device if timing is important, is probably the best advice.

(so sad...considering that from a playback audio quality standpoint,
SanDisk appears to have often been ahead of competition)

Received on 2015-11-21

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy