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.
Assuming you do that in GNU Radio, you'd end up with the problem of needing to know which end is a little faster than the other; and that's where things tend to get hairy, because GNU Radio not only runs very timing-undeterministically, but also consumes variable amounts of samples per Work call. You could try to estimate the average rate of samples going through a flowgraph, but then you're estimating a hardware clock rate with a software clock; I've got my doubts you'll get low enough estimator variance in short enough time without a lot of parameter tuning! At least, if you're in non-realtime userland (I'm told that Jack can do something like that; I just haven't caught up on that). Alternatively, you could take resampling action based on buffer fillage, but just like with a rate estimate, you've got timing uncertainties plus the fact that GNU Radio processes samples in uneven blocks, so you get a lot of Jitter, if you will, that ruins short-term estimates. For larger terms: If you can accept high latency, you can use larger buffers, and your buffer should "ideally" be half full (or whatever, constant fillage, just far away from completely empty of full). A control loop observing the downstream buffer writter's fillage (by simply looking at `noutput_items`) controlling a resampling ratio might work well - I just haven't tried. Ideally, you'd do that at the end with the high rate, to avoid seconds of audio buffers. But, that increases CPU load and also relative timing quantization (and reduces the "safety time" a larger buffer gives you). Alternatively, I could imagine someone hacks together a hardware frequency divider that one could feed from a software-superimposed Out- Of-Band tone produced alongside with the radio signal by the B200mini. Use that to generate the oscillator needed by an audio ADC. Would solve the underlying 2-clock problem at its source, but isn't really a flexible or generally applicable solution. Best regards, Marcus On Wed, 2019-03-06 at 10:53 -0500, Marcus D. Leech via USRP-users wrote: > On 03/06/2019 10:48 AM, Ian Buckley via USRP-users wrote: > > The elegant architectual solution (abstracted from GR) is to have a > > FIFO cross those 2 real clock domains, monitor the fullness and do > > closed loop sample rate adaption in reaction to the FIFO’s > > fullness…. > > Now I can also think of reasons why that would be tricky to do well > > in GR. > > It's a tad surprising that nobody has done an elastic buffer > implementation for GR. > > > > > > On Mar 6, 2019, at 1:47 AM, franz kurniawan via USRP-users < > > > usrp-users@lists.ettus.com> wrote: > > > > > > Hi all, > > > > > > i have struggling for couple of weeks in my AM transmitter > > > project. > > > i use audio source (alsa) as input and USRP sink (B200mini) as > > > output.. > > > i know that this making a "2 clock problem" and it will create > > > either underflow "U" or building latency between microphone > > > (audio source) and resulted radio transmission after several > > > hours of continuous running.. > > > i have tried some solutions below but none is working well : > > > > > > * set OK to Block to "No" in audio source to remove clock in > > > audio source. > > > Previously i have modified the source of alsa_source.cc since in > > > the OK to block feature in alsa is ignored in current version of > > > gnuradio. But the problem still persists > > > > > > * using tagged stream to enable the burst mode of USRP. But also > > > the problem still persists > > > > > > * manipulation of resampling rate with below formula: > > > interpolation : int(samp_rate * 1.000) > > > if i make the constant < 1.000 so that the consumer rate will be > > > slightly faster than producer rate, it will lead to repeating "U" > > > , but there is no latency. > > > else if the constant > 1.000 , there will be no "U" , but there > > > will be building latency.. > > > > > > > > > So, is there any proper solution to this kind of problem? > > > > > > Regards, > > > Franz > > > > > > > > > > > > _______________________________________________ > > > USRP-users mailing list > > > USRP-users@lists.ettus.com > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > > _______________________________________________ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
