[ntp:questions] Using NTP to calibrate sound app

Rob nomail at example.com
Tue Jan 29 17:43:48 UTC 2013

no-one at no-place.org <no-one at no-place.org> wrote:
>> Regarding: 
>>> Smartphone manufactures, for whatever reason,
>>> sometimes design a sound system that delivers 22,150 samples per
>>> second when my app requests that more standard 22,050.  By the way,
>>> this has not been a problem with Apple devices (iPhone/iPad), which
>>> all seem to be close enough to nominal without custom calibration.
>>> But Android devices and Windows laptops are a different story.
> On Tue, 29 Jan 2013 10:23:56 +0100, Uwe Klein
> <uwe at klein-habertwedt.de> wrote:
>>Can you modify your software to be rate agnostic/flexible?
>>the samling rate error you show is 4000ppm while crystal deviation
>>should not go beyond 50 .. 100 ppm ( 1 "cent" should be ~416ppm !?)
> My software is flexible with regard to audio sampling rate, provided I
> know what that rate is.  And that is exactly what my calibration does
> - discover the actual sampling rate by comparison to an external
> standard.  When I said that some devices give me 22,150 samples per
> second instead of 22,050 that was something I discovered through
> calibration.  There is no way for me to tell internally that the
> sampling rate is 22,150.  These devices do have an API that returns
> what they think the actual sample rate is based on what I requested.
> But even on the devices that are giving me 22,150 samples that API
> still claims the sample rate is the requested 22,050.  That API is
> mostly for use when a non-standard sampling rate is requested and the
> system has to find the nearest standard sampling rate that it can
> support.
> That 4000 ppm deviation is probably systematic and intentional, but
> you will have to ask the OEMs who designed the devices exactly what
> their intentions were in doing so.  I merely repond to what observe.

My theory would be that they require some crystal frequency elsewhere
in the device, e.g. for UMTS or WiFi operation, and that they divide it
by some integer to get the samplerate for the audio device.  That saves
them the cost and power consumption of an extra crystal oscillator. The
given crystal frequency does not evenly divide to 22050 (or 44100), but
they have chosen the nearest value.  The normal use of the device is
not affected, but your special use is.  I would find it reasonable if
they returned the actual sampling rate, but maybe that causes trouble
with apps that don't expect that and error out when the returned rate
is not equal to the value they set.

Once you have sufficient experience with calibration results and maybe
some inside knowledge from the developers of these phones, you may
be able to reduce your fine calibration requirement to just a decision
between a couple of alternative sample rates.  E.g. when you know the
rate is either 22050 or 22150, you can select the correct one much
easier than when you need to determine the exact rate.

What I still don't understand is why you cannot just use the local
clock to do the calibration.  Are you claiming that the devices that
have the 22150 sample rate also have a local clock that is running
fast by the same amount?   I would not expect that.  It would mean
the clock would run fast by 6.5 minutes/day, something that some user
would certainly notice and rightfully complain about.

More information about the questions mailing list