[Discuss-gnuradio] Re: Flowgraph running in "fits and starts"

[ikjtel]

On Mon, 6 Sep 2010 17:03:00 -0400 Tom Rondeau wrote:

>> A trivial change would be to have it loop until it it read
>> min(N_USER_SPECIFIED_ITEMS, noutput_items) items.
>>
>> Eric
>
> Indeed, this could be something we want to talk more about.
> Kind of on the periphery of my vision, I can see a handful
> of applications where the large chunking issue could be a
> problem. If we can define enough need, then we can talk
> more about finding the right way about it.
>
> Eric's suggestion is a good start. Tell it how many items
> you want and then run the loop based off that number or the
> noutput_items, whichever is smaller.  [snipped]

Just to continue this conversation, I got burned (again) by a
closely related problem.  It's the same overall block layout:
a GR source which produces symbols (dibits) at the 4800 rate,
the USRP sink runs at the 320K rate.  There's the usual intervening
GR blocks (RRC filter, resamplers, FM modulator, etc) to get
from 4800 dibits in to 320K complex samples out.

During the periods of time when the source is being supplied with
live audio (which happens to arrive at 8K s/sec.) it is possible for
it to output dibits at a nominal rate approximating 4800.  During
periods when the channel is idle*, things are not so clear but it
would still be possible for this GR source block responsible for
putting out dibits to generate zeros at a nominal 4800 rate.

However the *precise* rate *required* is of course "enforced" as
follows :
 - if the aggregate rate is too slow you will suffer the dreaded
   USRP underrun condition(s)
 - if the rate is too fast a backlog of queued symbols will
   accumulate "somewhere" and cause "delays", *easily* running
   into several tens of seconds worth

If I understood the above recommendations correctly, it is
totally left to the block that's emitting at the low-speed
rate (4800 in the present case) to somehow limit its own
output rate.

However the suggested method does not appear to enable the required
level of precision.  What is ideally wanted is some "just-in-time"
way for the low-speed block to produce its output.  Does GR
and/or its runtime have better knowlege as to when either of the
deadly sins (mentioned above) is incipient?  What guidance is
offered for the proper setting of N_USER_SPECIFIED_ITEMS, (above)?

It's well understood that there's an apparent conflict between
this and the desire for keeping the pipe filled so as to prevent
underruns...

*The "idle" problem has other interesting aspects; for example,
synchronizing the TX gating (PTT) signal timing with respect to
the complex sample stream, so as to properly mute (zero) them.
Due to the current way that samples flow thru GR, it could allow
large discrepancies in reckoning to creep in, because the
rate at which GR "demands" samples from the dibit source is so
disconnected from the rate at which they're actually consumed...

Best Regards

Max