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

[Marcus Müller]

Benny,

> RF block duration is directly propotional to audio frame durations.
100ms of RF block duration will corresponds to 100ms of audio.

no! And that's exactly the problem. In theory, it should be the way, but
because neither the RF clock nor the audio DAC rate are exactly what
they should be, this is not inherently true. And that's what Fons is
trying to solve.

Best regards,
Marcus
On 11/10/2016 02:36 PM, Benny Alexandar wrote:
> 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)
>