[ntp:questions] Using NTP to calibrate sound app
unruh at invalid.ca
Sat Jan 26 16:53:34 UTC 2013
On 2013-01-26, David Woolley <david at ex.djwhome.demon.invalid> wrote:
> no-one at no-place.org wrote:
>> small packets. A calibration run would consist of an initial NTP
>> syncronization with an audio packet, followed by a period of some
> What you are describing here isn't, I think, the use of NTP, but the use
> of SNTP. You seem to be making a measurement, form the server, over a
> short amount of time. True NTP measures frequency and time and does so
> over time periods long compared with the network and scheduling jitter.
>> number of minutes during which I will just count audio packets,
>> followed by a final NTP synchronization with the last audio packet.
>> By knowing the time difference over some number of audio packets I
>> hope to calculate the actual audio clock frequency for that device.
> The way to do it with NTP is to discipline the main clock frequency,
> over many hours, and then measure the time relative ot the system clock.
> You may well find that you don't have to measure the sound generator
> frequency because it may use the same crystal as the main clock.
Unfortunately ntpd does NOT change the crystal. It changes the way that
software interprets the output of that crystal (eg do 100000000
vibrations equal a second or do 10000002 vibrations?)
The sound cards are almost certainly hard wired into the crystal, not
software. Ie, the sound system does not, I believe, read the system
clock in order to time the sound output.
> Doing this simply, requires that you have some form of kernel discipline
> for the clock that is able to interpolate between ticks, allowing for
> the frequency correction.
> If you try and do SNTP measurements at the start and end of a sort
> period of tone, you will be very susceptible to network delay variations.
That will have to be within his error budget. Thus if the network jitter
is 1ms, then he would have to measure for 44 sec to get down to "one
cycle per 44000" error (ie +- 1Hz for a 44100 sound )
> Incidentally, given that all phone networks are digital these days, even
> your old method is susceptible to clock errors in the network, although
> I think most networks use atomic time.
More information about the questions