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.
> 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
