RE: Sound card clock accuracy

["Leif Åsbrink" <SMTP:LEIF.ASBRINK@xxxxxxxxxxxxxxxxxx>]

Hi Edson and All,

If you press T while running Linrad you will get the
sampling speed of your soundcard printed on the screen.

The evaluation is based on the number of samples received
and the total time elapsed since program start.

There is an uncertainty associated with the time of arrival
of samples. Samples arrive in blocks via dma and linrad is not
polling the device continously to see when a new block has 
arrived, there are other tasks (dsp processing) to attend to.

If you select a wide bandwidth for the first fft Linrad
will select a smaller dma size and dsp processing will be 
split in more but shorter tasks. Also deselect second fft
and afc to make the dsp processing minimum if you want to
get the sampling speed.

The value will start with a rather large error due to the
start/stop time uncertainties but as time goes along the 
sampling speed value will become gradually more and more 
accurate as long as no overrun errors are reported.

My Delta44 gives a final speed of 96003 Hz, (+30 ppm) which
is not unreasonable for a crystal oscillator that has no fine
tune capacitor. Part of the error may be the system clock.

It would of course be much better to use a good frequency
counter to check the crystal directly at 24.576 MHz 

73

Leif / SM5BSZ


> I'm trying to measure the accuracy of sound card clocks running under
> Linux and would like to discuss with people on the list about a posible
> method of measurement.
> 
> An indirect measurement I am using is to sample /dev/dsp at 8 kHz
> 1,000,000 times and compare time stamps (with millisecond resolution --
> ftime()) taken before and after the samplings. 1 million samples at 8 kHz
> should take exactly 125 seconds. I am measuring how off from 125 seconds 1
> million samples takes and from the difference I calculate the relative
> clock error. I am relying on the Linux system clock, so there will be some
> additional error, but it should not interfere much with the measurement.
> 
> Does any one see a problem with the way the measurement is being 
> performed? Any suggestion for improvements?
> 
> 73,
> 
> -- Edson, 7n4ncl
> 
> 
> 

LINRADDARNIL