[USRP-users] [Discuss-gnuradio] continous Tx voice transmission
ianb at ionconcepts.com
Fri Mar 8 02:54:15 EST 2019
Brian, I think your idea does work. I think the tricky bit to doing this really well is having a control loop that reacts quickly enough that we don’t have to be stuck with a giant buffer that adds undesirable latency, but then conversely a control loop that adapts at a slow enough rate and with small enough steps that we don’t introduce human perceptible audio artifacts.
> On Mar 7, 2019, at 7:46 AM, Brian Padalino via USRP-users <usrp-users at lists.ettus.com> wrote:
> On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller <marcus.mueller at ettus.com <mailto:marcus.mueller at ettus.com>> wrote:
> I've had rather longish discussions on how to solve this; essentially:
> for something that actually *solves* the issue (instead of postponing
> it), as Ian said, you'd need to have clock domain crossing ability.
> Could message passing from the real-time blocks solve this issue in a flexible way?
> Imagine the following: blocks connected to actual hardware use the computer wall clock to try to determine an average sample clock as it relates to the CPU clock. The USRP source block would be able to determine how many samples/(sec of CPU clock) were coming in and Audio sink blocks would be able to determine how many samples/(sec of CPU clock) were being consumed. The same idea for Audio sources and USRP sinks. Since the blocking calls for USRP or Audio blocks could be wrapped in a high precision timer, once any initial buffering had been filled up, the rate should settle out.
> The modified blocks could then send a message of actual sample rate to whoever needed to listen, and the appropriate sample rate could be figured out in the "resampling FIFO".
> What am I missing? Why won't this work?
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users