|
| From: | Benny Alexandar |
| Subject: | Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem) |
| Date: | Sun, 6 Nov 2016 09:58:05 +0000 |
|
Hi Marcus,
Thanks for the detailed explanation.
May be my understanding is wrong, please correct me if it is wrong. For example I'm using the DRM digital radio transmission and using the receiver for reception of digital radio. During live transmission the sound from microphone or other sources are
digitized and samples at a "nominal sampling frequency", and the oscillator used here for sampling the audio signals can drift. This is encoded and channel coded and transmitted.
I'm using USRP N210 to receive the digital transmission. USRP samples the RF input signal and converts to IQ signals and sends to PC or other hardware receiver. The receiver then does the channel decoding (OFDM demoudlation, carrier frequency offset correction
etc) and audio decoding and sends the audio output at "nominal sampling frequency" using audio hardware. So, the drift can happens in the following scenarios.
1. Transmitter crystal drifts which affects the audio sampling rate. 2. USRP uses separate crystal which can drift introducing drift on IQ samples.
3. PC audio hardware has to adjust these drifts to send the audio at adjusted sampling frequency to avoid buffer overrun/underun etc
I guess the drift in 2. can be adjusted through timing recovery as you mentioned. But what about the audio drifts ?
Since there are no timestamps send as part of transmission, to correct the drift in receiver the following can be applied.
Put a timestamp using receiver timer (micro seconds timer) and stamp every physical frame arriving at receiever. After audio decoding stamp every audio frame with the corresponding frame duration. Then when it is rendered at the audio hardware it can check
the current time and the packet time during every callback of audio frame and average the drift over some duration and correct the sampling frequency.
-ben From: Marcus Müller <address@hidden>
Sent: Friday, November 4, 2016 10:32:26 PM To: Benny Alexandar; address@hidden; address@hidden Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem) Hi Benny, 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...
Best regards, Marcus
On 11/04/2016 05:47 PM, Benny Alexandar wrote:
| ||||
| [Prev in Thread] | Current Thread | [Next in Thread] |