[Top][All Lists]

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

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

From: Benny Alexandar
Subject: Re: [Discuss-gnuradio] Broadcast Receiver Audio Synchronization ( Delay locked loop for the two-clock problem)
Date: Fri, 4 Nov 2016 16:47:55 +0000

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 <discuss-gnuradio-bounces+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]