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

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

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio