[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay

From: Fons Adriaensen
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)
Date: Sun, 13 Nov 2016 16:17:48 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Nov 13, 2016 at 02:46:57PM +0000, Benny Alexandar wrote:

[ Please use the <ENTER> key to limit the lenght of your text lines ]

> Only the receiver has to measure the drift and adjust to the incoming
> rate.
> ...
> So my problem is how to measure the ppm drift using timestamps from
> only the audio sink

You do not need to measure the rate error, at least not explicitly.
That is not how it works.

There will be some buffer between whatever provides the audio stream
(receiver, network, ...) and whatever consumes it (resampler or hardware
with adjustable sample rate).

If the rates are matched, then the *average* number of samples in that
buffer will be constant. Whenever it is greater than some target value
you increase the hardware sample rate. When it is lower you decrease
the hardware sample rate.

So the remaining problem is to find the average number of samples in
the buffer (and not to measure the 'ppm drift').

This is done by timing both the arrival and consumption of samples,
i.e. the write and read operations to the buffer. For each block
that is written or read, you mark the time 't' (using the same clock
for both) and you also keep a sample count 'k'. So on both ends you
have a series of (t, k),  These provide a piecewise-linear function
k(t), mapping 't' to 'k'. A DLL is used to ensure this is a smooth
function (in other words, one that is stays close to a straight line).

Then the average number of samples is the difference of these two
functions evaluated at the same time. This is compared to the target
value and the smoothed difference is used to adjust the hardware
sample rate. Note that this is a feedback system, and you need to
ensure stability.

That's it, I don't think I can explain it more clearly.



A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]