-----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/ iQEcBAEBAgAGBQJTWNP0AAoJEBQ6EdjyzlHt+NgH/jSLjf3WD60pZKg9NqMp72LL OFrblVt9/f3ashUgzOgaPFUcMSV75c/f+1V8L/wVhdNS6WCx3P9r9JD5Y4Xs3z8A TiG1UACngyRpomqI8TbGn929mFgi5nkBGQQ6F2gFmzv68LzToFifC4mwBH5jtA1J ELUQDXmcymfKdjuUEeiOLin5CeXnXueUqbfPRVA5ouEV1XBoXMyhP5r7XY5ME1Fa zyZuNIUubWUnYWRFjlhAuTLwpFjMWQc0MwmSxw0eLRlfuVYubGOJZm1TFNSbTCGm O8KL/DhIE5cKagmOg57xO+9QS3u3givrGDjBPa++dkdONXCFsDeMZCaYncfjPWQ= =29EU -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
