Re: [Discuss-gnuradio] GRC flow graph taking longer than I think it should

[Marcus D. Leech]

On 03/06/2017 03:18 PM, Thomas Wright wrote:
> Thanks for the info. Would writing the same program using c++ gnuradio 
> apis give better performance? is there anything else we can to to 
> significantly improve performance aside from not using gnuradio? 
> Thanks again.
>
> -Scott
You can modify latency by changing buffer sizes, for example, in the 
"options" block you can specify the max_items.

But buffer management, which trades-off *throughput* vs *latency is a 
tricky subject.  Folks other than me probably have better insights
  into the Gnu Radio scheduler to help make these trade-offs.   By 
default, Gnu Radio is optimized for *throughput*, which means that
  latency can take a hit--ESPECIALLY at lower sample rates.  Even a 
"modest" 16K-item buffer will incur 80 or so msec of latency at
  195Ksps.

Also, you're using old-style message queues, which are, I believe 
deprecated.

It would be better to learn how to write your own OOT processing block, 
than to stuff raw data into a (obsolete) message queue, and have
  "ordinary" python code process it.