discuss-gnuradio
[Top][All Lists]
Advanced

[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: Wed, 9 Nov 2016 21:26:50 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Nov 09, 2016 at 05:12:25PM +0000, Benny Alexandar wrote:

> So the logic is whenever an audio compressed frame arrives at the audio codec,
> it is timestamped with the current time (Ti) and after uncompressed each audio
> frame blocks (24ms) is timestamped by adding 24ms ( Ti + ( frame_no * 
> frame_duration )),
> where Ti is the start time and frame_no is the decoded uncompressed frames 
> ranges from
> 0 to n and frame_duration is 24ms.

That doesn't make much sense, for at least two reasons.

First, the time when a compressed frame arrives at the codec has no
meaning. At that point the signal is just data stored in memory, not
a physical one. The only time that would make sense would be the
timestamp at the A/D converter of the RF sample that in some way
corresponds to the start of the compressed frame. And even that
assumes that there is simple linear relation between the RF samples
and audio samples.

Now that doesn't mean that such timestamps can't be used. But you
can't use them in the naive way you describe.

Second, if you read the timer once and then just add the nominal 24ms
for all following timestamps, you don't get any information about the
data rate at all. Simple reason is only the first timestamp contains
any new information, all the others are redundant because they can be
computed from the first. But maybe I misunderstand that part of your
scheme.

> ... After some N seconds this accumulated value is averaged by dividing
> by N sec. So I get the drift in sampling rate in terms of samples.  
> Then all I need to do is slow down or speed up the sampling rate based
> on which side the drift is.

You'd need to do this continuously. A single correction can't be perfectly
accurate, and any remaining error is integrated w.r.t. time and will grow
without bound. And you can't assume the sample rate ratio is fixed, it
will drift as well.
 
> Is it possible to change the sample rate of ALSA by drift amount ?

On a few professional (and very expensive) audio cards allow continuous
control of the sample rate, e.g. RME's MADI interfaces.


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)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]