-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Bolin,
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 block > 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 can continue. > So my intention was to add functions to the scheduler to allow > pause and resume from python via top block. When paused, > 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 http://gnuradio.org/doc/doxygen/index.html#latency . 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. Greetings, Marcus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWMPTAAoJEBQ6EdjyzlHtoqcH/RzAKsfHAL2adT4D1rsof9G3 11XrkUL0//yCopT+7zawKnUKtUNJJ+6/Eu3DG23mWR/irqTYBCPbM/CTOsS6m7bz ZlRFBtHJslNLk0426QPA7IOisvy1O23ESk4eR5enxDRfHlp5K6cMXYRDuOZ8k9hi Ur7oQUmwKQSP9NObidc0odnDRfz9lkS1RWW+n4sSX3hA3tFpkrJnlrGyW/dQ9Awp SUBHhreS+skXSXvYAMwB0U6eWLKk0+EQEeec5R6zqQ2tuBO5UcoXE2OJuGYPWaJt EVoB4ZuKOgIntjPiRMNV7xus2hyu5eBzxvQoY7W0E9RGXBcxRp4nWH0jjjpbhYA= =ZzcD -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
