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