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

[Fons Adriaensen]

On Thu, Nov 10, 2016 at 04:17:25PM +0100, Marcus Müller wrote:
 
> > RF block duration is directly propotional to audio frame durations.
> > 100ms of RF block duration will corresponds to 100ms of audio.
> 
> no! And that's exactly the problem. In theory, it should be the way, but
> because neither the RF clock nor the audio DAC rate are exactly what
> they should be, this is not inherently true. And that's what Fons is
> trying to solve.

Well, assuming constant bit rate audio coding, on average T seconds
of RF will correspond to T seconds of audio. But that is besides the
question. 

We have

  codec -> [ buffer -> resampler ] -> audio HW.

where [...] is the audio sink block. The buffer is *an internal part*
of the audio sink, and *not* the one that gr provides to connect codec
and audio sink. 

The resamping control loop will try to have on average a constant
number of samples in this buffer. For this it needs timing info on
both the incoming and the outgoing blocks of data, using the same
clock for both. The clock used on the audio HW side is part of the
audio sink block, and the same must be used for buffer writes. That
means that only the audio sink block can do meaningfull timing of
the buffer writes, and any other info provided by upstream blocks
is useless. That's also why the buffer is part of the audio sink.

In other words, on the write buffer side the timing is that of
the audio sink work(), and on the read buffer side the timing is
that of the audio driver (or jack) callback. No external timing
info is needed.
 
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)