-----BEGIN PGP SIGNED MESSAGE-----
my compliments for being this investigative on your issue!
My understanding of the flow graph execution was a scheduler
checks the blocks in a round robin fashion, and execute the work
function of a
if the block can make progress.
Not really. As you notice further on, the scheduler is called “tpb”,
which stands for “thread per block”.
What happens is that every block is executed in its own thread, which
sleeps until one of the neighbor blocks notices the scheduler that he
has done some work and the scheduler notfies the block thread that it
So my intention was to add functions to the scheduler to allow
pause and resume from python via top block. When
the scheduler won’t run any block’s work function.
Interesting, yet I don’t understand why you would want to do that. How
does that paused time help you reduce your latency?
If I understood you correctly, the number of samples until your
frequency offset estimator has come to an estimate plus the number of
samples that are already in the pipeline between that estimator and
the frequency correction is very large (44.1kHz*0.6s =~ 30,000). I
still blame that on the estimator and I don’t think you can solve
that “information theory sampling time” latency issue by stopping
“reality processing time”…
You can try to reduce the number of samples that are being worked on
each time (set_max_noutput_items) or even limit the maximum buffer
size between two blocks (set_max_output_buffer_size), which both might
hurt you. Please have a look at
Anyway, have you had a look at gr::top_block::lock()? It’s meant to
stop the flowgraph prior to reconfiguration (which in “official” GR
lingo means you dis- and reconnect some blocks). I think there was a
discussion yesterday about if that empties buffers, and I think it
doesn’t touch buffers of connections you don’t change. I’m not quite
sure about that, though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----