Latency control. You asked for it

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs