|Subject:||Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)|
|Date:||Fri, 4 Nov 2016 18:02:26 +0100|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0|
Drift between what and what?
So, drift between the RF receiver hardware and the transmitter: that's job of the timing recovery in the receiver.
The output of that is an audio signal that is correctly resampled
for the *nominal* sampling rate of the Soundcard, measured in
nominal sampling rate of your RF device.
Now, the Audio over and underrun problems happen because these nominal rates are derived from two different oscillators and don't agree.
So, there's two problems:
1. Receiver Timing recovery (solvable in software)
2. Resampling to match the actual audio hardware sampling rate
so, for 2., Fons' approach is described in his papers. The resampling isn't actually the problem, the estimation of frequency offset is.
The question on how to get timestamps from the receiver is a) RF
hardware specific (for example, as far as I know, the USRPs are
pretty much the only devices that add timestamps – but I think I
might be wrong) and b) irrelevant to the problem of resampling,
because a timestamp from the receiver device is completely
independent from a time in your PC and both are independent from
how fast your audio hardware's sampling rate is. Really.
Imagine you have three rooms, each with a clock on the wall. All
three clocks run slightly wrong, and all were set to 12:00 at
different times, and all you do is put things into parcels in the
first room, strap that parcel onto the back of a tortoise and tell
the tortoise to go to the next room. The timestamp you put on the
parcel in the first room will not be that much help in the second
room, aside from telling you roughly how late it was in the first
(RF hardware) room when the tortoise started to go into the second
room (CPU). You can then take the samples out of your parcel,
process them and put them into another parcel strapped to a
tortoise aiming for the third room (audio hardware).
The problem at discussion here is how to estimate the individual clock's speed differences (since there is no inherently "true" clock), purely based on when the tortoises arrived in the next room – and while we're at it, eliminate the effects of the tortoises being unevenly motivated, unevenly loaded, and randomly delayed, all while the clocks drift faster than the tortoises move...
On 11/04/2016 05:47 PM, Benny Alexandar wrote:
|[Prev in Thread]||Current Thread||[Next in Thread]|