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
