Re: [Discuss-gnuradio] [USRP-users] continous Tx voice transmission

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@lists.ettus.com> wrote:

On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller <marcus.mueller@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?

Brian

_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com