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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
