[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay

From: Marcus Müller
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

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,


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 Fons ADRIAENSEN, Casa della Musica, Pzle. San Francesco 1, 43000 Parma (PR), Italy, address@hidden Abstract Combining audio ...

[3] Adriaensen, Fons: "Using a DLL to filter time", 2005, http://kokkinizita.linuxaudio.org/papers/usingdll.pdf
Using a DLL to filter time Fons ADRIAENSEN Alcatel Space address@hidden Abstract A new mechanism to obtain an accurate mapping between samples and system ...


From: Discuss-gnuradio <address@hidden> on behalf of Marcus Müller <address@hidden>
Sent: Friday, November 4, 2016 3:52:18 PM
To: address@hidden
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

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,

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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]