|
| From: | Marcus Müller |
| Subject: | Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem) |
| Date: | Sun, 6 Nov 2016 14:17:17 +0100 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 |
|
Hi Benny,
On 06.11.2016 10:58, Benny Alexandar
wrote:
Well, since you can never recover that drift (it's not among the information being transmitted), let's ignore the Soundcard-ADC vs. transmitter RF sample clock offset, for now. Let's assume your transmitter used a sampling clock that was nominal 1 MHz, but in reality was 1 MHz +- Err Hz; so "1 Hz" isn't really 1 Hz in respect clock – let's call the "imaginary reference close-to-1 Hz frequency" of the the transmitter f0; the sampling clock is simply 1 million times as fast as that. The symbol rate of the transmitter is thus "correct" relative to f0; so if the nominal symbol rate of a DRM transmission (I know, it's OFDM, so things are more complicated, but let's simply talk of a symbol rate) is 40kS/s, we know that within one f0-oscillation, there'll be 40,000 symbols, or, to put it like you really see it in the DSP system, one symbol is 1 Million / 40 thousand = 25 samples long So you receive an RF signal: Exactly, so you get samples sampled at another sampling rate, which isn't really the sampling rate that it said it is, but has some error. Again, we get a "local virtual close-to-1Hz" f1. yep, and that means that uses a resampler to resample the received symbol rate from being referenced to f1 (and thus, for example, 38400 symbols per f1 oscillation, or 24 samples) back to the nominal samples per symbol rate (ie. 40,000 S/s, or 25 samples per symbol). Exactly! so, the receiver then produces an audio stream with 48k audio samples per 40k DRM symbols – but those 40k DRM symbols come in at a speed relative to f0. Sadly, the sound card runs from a different oscillator, so it has a f2....
That's what the timing and freq sync in a receiver solves Well, the Audio hardware has jet another oscillator, and that, to be honest, is the least exact one of all oscillators involved. That's exactly the problem that Fons'/Jack's DLL should solve – and it seems to work, but it works because it's closely tied to the audio processing, and I'm not 100% convinced that it'll work for things that run at rates much higher than Audio (no problem for you, you want to do audio), and I'm also not 100% convinced it'll work anywhere but directly at the Audio infrastructure, because with additional things between the rates to be compared, I believe the DLL will get at the mathematical boundaries of what is possible to stably correct. There's timestamps, inherently, because if you know the sampling rate rel. to f0 (which you do, after timing recovery), you could agree on a "symbol number 0" and just count symbols (instead of counting seconds). But it doesn't help anyone, because your sound card doesn't care about any real-world/transmitter/receiver oscillator-relative time... it just runs at something like 47.98kHz (measured relative to f0), and you have live with that. What Jack's DLL does is: measure the time between two audio sample packets arriving, and based on that, measure the input sampling rate; also measure the time it took a soundcard to consume an amount of samples, and with that measure the output sampling rate. Then compare and resample accordingly. It works for audio rates with PC hardware, it seems. The problem I have with this is that we get a fourth clock involved here: it relies on the OS'es "microsecond-accurate time", and that runs at an oscillator in your CPU or on your motherboard, and thus, relative to a f3. Again, for audio stuff, the short-term stability and accuracy of that clock should be good enough for that delay-based estimation; if you wanted to synchronize MS/s streams, that might change, IMHO. So the main technical problem that we have is that whilst this DLL (I'd just call it a buffer-fillage control loop) is conceptually nice to understand, no-one has implemented it within GNU Radio – if you found yourself able to write it for ALSA (not much sense writing it for the Jack sink, if Jack can already do it internally), we shall surely find a way to "upstream" this and help you with code review! The closest we have now is the probe rate block – which really just does that, count the items flying by, divide them by the time passed, and spit out a message containing item rate relative to CPU time (f3). Combine that with an audio sink that estimates the audio sample rate based on the same CPU time, and you might have everything you need to instruct an adaptive resampler. Best regards, Marcus
| ||||
| [Prev in Thread] | Current Thread | [Next in Thread] |