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

[Benny Alexandar]

>> If you mean that the internal buffer isn't needed and that the gr buffer can take
its role, that's not going to work.

This is what I'm thinking of.
All the packets which are put into the input queue of audio sink has
to be timestamped using the same clock used in audio sink. Pass this
timestamp info as part of metadata of packet. Every packet in the queue
has a timestamp which tells the time of last sample W(t), and how many
samples k(t).

First time when audio sink receives the  packet, it reads the current time
c(t) and packet timestamp W(t). Add a fixed delay (D) to the packet timestamp
to delay the audio playback.  

deviation = W(t) + D - c(t)    ----->   (1).
The delay is such that equ (1) never becomes negative.

When audio hardware finishes playing out R(t) of each packet data it interrupts
and in isr callback calculate equ (1) for next packet and average deviation.

This in effect reflects the internal buffer operation exactly.  

-ben

---

From: Fons Adriaensen <address@hidden>
Sent: Tuesday, November 15, 2016 1:44:37 AM
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 Mon, Nov 14, 2016 at 04:59:24PM +0000, Benny Alexandar wrote:

> I have some questions regarding it.
> How many blocks of audio the internal buffer  need to store ?

Enough to keep feeding samples to the audio HW until the sink's
work() is called again.

> 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 ?

When gr calls the sink's work().

> 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.

The sink's work() will block until all input data is transferred
to the internal buffer.

> Why not handle this with gr buffer ? Audio sink can query the
> available data in its input queue.

I don't understand what exactly you mean. If you mean that the
internal buffer isn't needed and that the gr buffer can take
its role, that's not going to work.
 
> 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 ?
 
It's just an example, illustrating what happens in that case.

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)