Clock Drift Compensation

Clock Drift Compensation (CDC) is mechanism used to handle situations when the audio clocks on both the record and playback devices are not exactly matched. A relevant example is when streaming audio through a SPARK RF link. One board will record the samples and the other one will play them back. The audio clock is asynchronous between both boards. This means that even if both audio master clocks are theoretically the same frequency and a sampling rate of 48 kHz is configured, the effective sampling rate on both boards could be slightly different due to crystal tolerances. This could lead to a device having a sampling rate of 47.980 kHz while the other has 48.030 kHz for example. In such situations, the clock drift needs to be compensated or some audio glitches will happen.

The CDC is done in two stages: drift detection and drift correction. The detection mechanism is basic and tailored around the use of a SPARK wireless link. For correction, the Audio Core provides two different approaches; one is software-based and the other is hardware-based.

Drift Detection Mechanism

The default detection mechanism provided by the Audio Core is the monitoring of the audio buffer (consumer queue) on the receiving end and averaging its load over time (sliding window). If the average is below a certain threshold (depleting) or over a certain threshold (filling), the audio clock will be considered “drifting” and a corrective action will be triggered. The audio header contains a bit called “TX queue level”. If that bit is set, the receiver/playback device will conclude that the audio buffer load variation is caused by bad RF link conditions (and not clock drifting), and therefore no corrective actions will be triggered in that case.

The average length should be decided based on the maximum amount of drift to be compensated. For example, if the maximum drift to be compensated is 100 ppm, the difference in number of samples generated between the two systems would be ((100 / 1000000)) * 48000) = 4.8. The consumer queue size averaging must thus be fast enough to measure every (1 / 4.8) = 0.2083 seconds and also have time to apply the drift correction mechanism.

Drift Correction Mechanisms

The Audio Core provides two different approaches to drift correction: software resampling and hardware Phase-Locked Loop (PLL) clock adjustment. Software resampling can be used on any hardware whereas PLL clock adjustment requires specific hardware features.

Software Resampling

Software resampling requires an interpolation method. By default, linear interpolation is used.

The SPARK resampling library uses a fixed block size (e.g., 1440 samples) to define the resampling period. The resampling period is thus block_size / sampling_rate (ex: 1440 / 48000 = 30 ms).

At the end of the resampling period, a new sample is either added or dropped. A sample is dropped when the audio clock on the playback device is slower than the one on the recording device, and a sample is added when the audio clock on the playback device is faster than the one on the recording device. CDC must be enabled only on the playback device and not on the recording device.

This sample manipulation has minimal impact on audio quality, but will act as a low pass filter. Signals close to the nyquist frequency will be attenuated which will lead to amplitude drop when the resampling process is running.

Phase-Locked Loop (PLL) Adjustment

This mechanism leverages the hardware’s ability to precisely adjust its internal PLL. When a drift is detected through buffer load variations, a small adjustment of the PLL’s fractional part is applied to correct the timing. Monitoring is fine-grained, with continuous, smooth corrections resulting in minimal clock jitter.

Warning

The CDC detection mechanism provided by the Audio Core does not support use cases with a single producer providing the same data to multiple consumers on the same device (e.g., codec as source (producer) and 4 different wireless connections as consumers).