Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

[Benny Alexandar]

Hi Fons,

Thanks for the detailed explanation.

I have some questions regarding it.
How many blocks of audio the internal buffer  need to store ?
When does the copy from gr buffer to internal buffer happens ? Is it
during the audio hardware driver call back or during gr scheduling the
audio sink ?
Before copying to the internal buffer the audio block has to be played
to prevent overwrite of data. In a way it has to do the same check
what the gr buffers do, space is available to copy etc.  
Why not handle this with gr buffer ? Audio sink can query the
available data in its input queue.

I was reading the paper "usingdll.pdf" in that the first figure (fig 1)
( The thin (blue) line is the exact mapping we want. Note
that in this example the real sample frequency is
slightly lower that the nominal — the thin line
is lagging the grid as time advances.)

In an ideal case the thin blue line should intersect all the grid points.
Why the real sample frequency is slightly lower than nominal ?

-ben

---

From: Fons Adriaensen <address@hidden>
Sent: Sunday, November 13, 2016 9:47:48 PM
To: Benny Alexandar
Cc: Marcus Müller; address@hidden
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)

 

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.

Ciao,

--
FA


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)