[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: Mon, 14 Nov 2016 20:14:37 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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.



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]