Hi Benny,
On 06.11.2016 10:58, Benny Alexandar wrote: > > 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. > 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: > > 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. > 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. > > The receiver then does the channel decoding (OFDM demoudlation, > carrier frequency offset correction etc) > 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). > and audio decoding and sends the audio output at "nominal sampling > frequency" using audio hardware. > 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.... > 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. > That's what the timing and freq sync in a receiver solves > > 3. PC audio hardware has to adjust these drifts to send the audio at > adjusted sampling frequency to avoid buffer overrun/underun etc > Well, the Audio hardware has jet another oscillator, and that, to be honest, is the least exact one of all oscillators involved. > > > I guess the drift in 2. can be adjusted through timing recovery as you > mentioned. But what about the audio drifts ? > 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. > > > Since there are no timestamps send as part of transmission, to > correct the drift in receiver the following can be applied. > 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. > > > 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. > 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 > > > -ben > > ------------------------------------------------------------------------ > *From:* Marcus Müller <marcus.muel...@ettus.com> > *Sent:* Friday, November 4, 2016 10:32:26 PM > *To:* Benny Alexandar; discuss-gnuradio@gnu.org; f...@linuxaudio.org > *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: >> >> Hi Marcus, >> >> >> I have read the papers from Fons, and was interesting to know how the >> algorithm implements the control loop. For broadcast receiver also >> the same can be applied. Here the received audio will be in blocks >> of samples and the output audio rate can drift due to crystal >> inaccuracies. >> >> >> How to estimate the drift in case of broadcast receiver ? >> >> How to get the timestamps for broadcast receiver ? >> >> >> [1] http://kokkinizita.linuxaudio.org/papers/adapt-resamp-pres.pdf >> [2] Adriaensen, Fons: "Controlling adaptive resampling", 2012, >> http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf >> >> Controlling adaptive resampling - Linuxaudio.org >> <http://kokkinizita.linuxaudio.org/papers/adapt-resamp.pdf> >> kokkinizita.linuxaudio.org >> Controlling adaptive resampling Fons ADRIAENSEN, Casa della Musica, >> Pzle. San Francesco 1, 43000 Parma (PR), Italy, f...@linuxaudio.org >> Abstract Combining audio ... >> >> >> [3] Adriaensen, Fons: "Using a DLL to filter time", 2005, >> http://kokkinizita.linuxaudio.org/papers/usingdll.pdf >> <http://kokkinizita.linuxaudio.org/papers/usingdll.pdf> >> Using a DLL to filter time - Linuxaudio.org >> <http://kokkinizita.linuxaudio.org/papers/usingdll.pdf> >> kokkinizita.linuxaudio.org >> Using a DLL to filter time Fons ADRIAENSEN Alcatel Space >> fons.adriaen...@skynet.be Abstract A new mechanism to obtain an >> accurate mapping between samples and system ... >> >> >> >> -ben >> >> ------------------------------------------------------------------------ >> *From:* Discuss-gnuradio >> <discuss-gnuradio-bounces+ben.alex=outlook....@gnu.org> on behalf of >> Marcus Müller <marcus.muel...@ettus.com> >> *Sent:* Friday, November 4, 2016 3:52:18 PM >> *To:* discuss-gnuradio@gnu.org >> *Subject:* Re: [Discuss-gnuradio] Broadcast Receiver Audio >> Synchronization ( Delay locked loop for the two-clock problem) >> >> Hi Ben, >> >> Ok, I'm not 100% sure I'm following you here: >> >> "Broadcast Receiver Audio Synchronization w.r.t Transmitter Clock" >> >> is of course what you'll need to do, mathematically, anyway, and any >> reasonable receiver has some kind of timing recovery (sync) >> functionality that does that, in order to be able at all to extract >> symbols from the signal correctly. >> >> So, in hardware, this is a bit easier, because your receiver can define >> the clock of your Audio device. In other words, there can be no >> underflows/overflows, because you make your audio hardware work at a >> rate derived from the symbol rate. >> >> With PC hardware, that possibility doesn't exist: You can't tell your >> sound card to run with a specific physical clock – it has its own, >> independent oscillator, which you can't influence. >> >> So, no, there's no GNU Radio blocks to influence your Audio hardware's >> clock, because that is impossible. >> >> However, you're asking about resampling: Well, resamplers do exist :) ! >> We've got a totally different problem, though: To resample properly, >> you'd need to know (or better: estimate) the clock error. For audio rate >> systems, Fons has a proposed architecture that looks promising and is >> already implemented within the Jack Audio architecture, as far as I can >> tell. >> >> Seeing that it works in Jack for audio resampling there, that's the way >> I'd go: Use Jack. In fact, maybe it's relatively easy to get this >> running. Problem is that if I understood Fons correctly (he seemed a bit >> upset about that at the time), the Jack sink is currently broken, and he >> seems to be the only one who touched that in a while, so no-one fixed >> that. >> >> Now, most Linux distros these days use Pulse Audio anyway, and use that >> as an ALSA backend >> >> GNU Radio Audio sink (libalsa) --> "default" ALSA device (loopback) --> >> Pulseaudio (using libalsa) --> actual audio hardware >> >> For Pulseaudio, a Jack backend exists, so you could configure your Pulse >> audio to do >> >> Audio Sink -> "default" ALSA device -> Pulseaudio -> Jack -> resampling >> incl. DLL -> ... >> >> Notice that I'm absolutely no expert in Pulseaudio, Jack, or ALSA >> configuration, so this will be quite some trial and error, if it doesn't >> work right away. >> >> Best regards, >> Marcus >> >> On 04.11.2016 10:40, Benny Alexandar wrote: >> > Hi, >> > >> > Broadcast Receiver Audio Synchronization w.r.t Transmitter Clock >> > >> > This can be applied to broadcast receiver where, for broadcast >> digital raido receiver the audio output buffers will undergo buffer >> overflow or underflow if the audio clock is not adjusted to the >> transmitter clock drift. >> > This needs resampling of audio at the receiver side based on the >> drift in transmitter clock or other drifts due to crystal >> inaccuracies in receiver. >> > In Gnuradio any blocks available to introduce transmitter drift of >> transmitter ? >> > >> > -ben >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
