On Wed, Mar 6, 2019 at 3:12 PM Marcus Müller <marcus.muel...@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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
