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
