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: Benny Alexandar
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)
Date: Thu, 10 Nov 2016 13:36:35 +0000

Hi Fons,

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

Yes, thats right. But now the problem is RF samples are captured by USRP and
is passed to PC for further processing. So, if USRP timestamps the RF block of 
samples
it will be based on a different clock. For example the timer used in USRP is 
2MHz counter,
 when it is received at PC side clock conversion is required to match the PC 1 
MHz counter.
Can this conversion affect the timestmaping at PC side because of round off 
error?

RF block duration is directly propotional to audio frame durations. 100ms of RF 
block duration will corresponds to 100ms of audio.
Otherwise it won't be continuous audio streaming. This is my understanding, 
please correct if I'm wrong.

-ben
________________________________
From: Fons Adriaensen <address@hidden>
Sent: Thursday, November 10, 2016 2:56:50 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 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]