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

On Tue, Nov 15, 2016 at 05:14:41PM +0000, Benny Alexandar wrote:

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

No, for various reasons. I could try to explain things yet again,
but I'm gradually out of patience. If you have any bright ideas
about this please do your homework and verify them - by pencil
and paper, by simualation, or by really implementing them. That
way you'll learn a lot more than by launching random ideas and
let me kill them. 



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]