|
From: | Marcus Müller |
Subject: | Re: [Discuss-gnuradio] [USRP-users] Audio Control loop testing |
Date: | Mon, 18 Sep 2017 22:40:39 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
Hi Ben,
that's the old multi-clock problem we've been talking about multiple times – it's hard to even define what the "correct" clock is, so you usually just settle on recovering the transmitter clock and, if you were doing this in hardware, would derive the audio DAC's clock from that. In a software receiver, you need to estimate the offset of the
audio DAC clock from the sender's audio clock. That's hard to do
properly, because these clock offsets might be to fine to do it
with general purpose PC CPU software. But we've talked about all
that before on the Discuss-gnuradio list!
As a way around that, you might use the same clock to derive the
RF receiver's sampling clock and the audio DAC's sampling clock.
You then get a direct relation between RF sampling and audio
playback, for example "every 1 million RF samples, I need to
produce one audio sample". Fons and I really tried to explain that
in about 20 emails on discuss-gnuradio. So, I think we've covered
the stage of "any suggestions on this would be helpful" pretty
well. It is a hard problem, and there's a solid chance you can't
solve it for all use cases in software. There's also a solid
chance you might be able to solve it for a specific use case, but
that would require you to become an expert on multi-rate
processing and clock matching, and frankly, you're not showing
much progress at that over last 10 months.
Best regards, Marcus
On 09/16/2017 05:38 AM, Benny Alexandar
via USRP-users wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |