Some of you at least.
There's been an expressed desire for better control over the latency of a
GNU Radio flowgraph. I've just checked in an update to the master (and
next) branch that gives you a bit of control over this. Now, when you call
tb.start() or tb.run(), these functions take a parameter that specifies the
maximum noutput_items a block can ever receive. This means that the most
latency you'll see in a block is based off this number.
If you don't change anything in any existing applications, nothing will
change as the default is a huge number that no block will ever be asked to
process.
For those running graphs with lower latency requirements, it'd be great if
you could test this out and report back success or failures.
Also, for running wxGUI applications, you set this value when create the
stdgui2.stdapp as the last parameter called man_noutput_items like in the
uhd_fft.py app:
app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1,
max_noutput_items=8000)
Tom
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
