0
$\begingroup$

I have a simple program that captures audio from an audio device. I have configured a nominal sample rate of 48000Hz and a buffer size of 1 millisecond. The audio sub system should execute my capture code with approximately 1000Hz.

My assumption is that the audio clock (LRCLK) is not running at exactly 48000Hz. Using this 1kHz-callback from the audio system I want to approximate the actual sampling frequency relativ to another clock. Currently I use the system clock of my workstation as a reference. I plan to use a network clock.

For my very first experiment I used a simple moving average with a period of 1000 but there is still very much jitter. Sometimes the average jumps by 2Hz which seems much to me.

What is the proper way to go here?

Many thanks!

Improve this question
$\endgroup$
5
  • $\begingroup$ Can I please ask if the "audio device" is a sound card or other codec chipset? Also, how do you derive that 2Hz jitter? (Is it via sampling a reference sinusoid for example?) $\endgroup$
    – A_A
    Nov 28 '16 at 20:34
  • $\begingroup$ Currently I'm working on a PC with an on-board sound card. I plan to work on embedded devices in future though. The 2Hz jitter comes from my first experiment with a simple moving average. I sample the duration between calls to my capturing code which should be called with ~1kHz. The window has 1000 samples. From the average duration I derive the approximate sampling frequency in Hz. One example of extrem jitter is this sequence: 48000.6, 47974.1, 48025.2 $\endgroup$
    – Jan Deinhard
    Nov 28 '16 at 21:36
  • $\begingroup$ You will never get rid of that with an off the shelf sound card. Try an ASIO capable piece of hardware. It will run smoothly and go as low as buffers of 256 samples at 44.1kHz with absolutely no problem at all (that's approximately 5ms by the way). $\endgroup$
    – A_A
    Nov 28 '16 at 21:41
  • $\begingroup$ But even with better audio hardware I assume some jitter is always expected right? The question remains: How to approximate the actual sampling frequency relativ to another clock. I can measure the duration between the calls to my code. I also consider to go "nearer" to the hardware (interrupt handler) to get rid of system related jitter. $\endgroup$
    – Jan Deinhard
    Nov 28 '16 at 21:53
  • $\begingroup$ I can assure you that there is no noticeable jitter on an ASIO capable sound card. If there is jitter it is excruciatingly low (much, much smaller than the sampling period). You would discover it by measuring it (over a very long period of time), not by ear. What you are looking for is resampling and ultimately interpolation beteween the sample rate of one clock and another assuming that both can keep their "tempo" once started. $\endgroup$
    – A_A
    Nov 28 '16 at 22:01
2
$\begingroup$

In my experience, sound card sampling clocks vary by as much as 10 Hz from one card to another, even between computers of the same make and model. I have never seen much jitter, but I haven't especifically looked for it.

Note, however, that it is essentially impossible to know the true sampling rate, unless you have access to an atomic clock. What you can do is approximate the difference relative to a clock that you designate as your reference.

A simple experiment is to generate a single-tone signal, then receive it and find its frequency. Say your reference is the transmitter and it's operating at 48,000 samples per second. Feed the transmitter a sequence 0, 1, 0, -1, 0, .... This will produce a sine wave of nominal frequency 12,000 Hz. In the receiver, you sample this signal for a relatively long time (to have good frequency resolution) and use the DFT to determine its frequency to be, say, $f_2$. Then, you can calculate $$\Delta=\frac{12000}{f_2}$$ which is the factor by which the receiver's clock is faster than the transmitter's. Of course, this is only one of many possible approaches.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Sorry for being inaccurate. I want to approximate the sampling frequency relative to another clock. Right now I use the system clock as the reference. Later I want to use a synchronized network clock (IEEE1588/PTP). $\endgroup$
    – Jan Deinhard
    Nov 28 '16 at 21:39
  • $\begingroup$ May I ask what you mean by jitter? I expect drift between clocks on different computers because the clocks are running at more or less than the nominal sampling frequency. But as long as the temperature is not changing I do not expect much jitter between the interrupts from the audio system. Maybe I am working at the wrong system level. Thank you very much for the suggested experiment. I will definitely consider it but in the end I would like something which derives the factor "on the go". $\endgroup$
    – Jan Deinhard
    Nov 28 '16 at 21:46
  • $\begingroup$ @JanDeinhard By jitter I mean a fast, random change in the clocks' frequencies (sort of like phase noise). I've re-read your question and it seems you were actually refering to jitter caused by your measurement method, which is based in software. If that's the case, we're referring to different things. $\endgroup$
    – MBaz
    Nov 28 '16 at 22:19
  • 1
    $\begingroup$ @JanDeinhard There are methods to adjust the timing "on the go". In digital communications (my field), the receiver and transmitter are never perfectly synchronized so the receiver's clock needs to be constantly adjusted. Search on this site or google "symbol timing synchronization", "gardner algorithm", "mueller and mueller algorithm". These work with specific kinds of signals, but you may be able to adjust them to work with your system. $\endgroup$
    – MBaz
    Nov 28 '16 at 22:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.