Very useful! I found that my solution to the problem was to just let the FG drain by itself and just minimize latency elsewhere. That said... If a source stops pushing data into it, does it mean the samples still in the buffers in other blocks get processed, or do they get stuck there until new data pushes them out? To the best of my experimentation when I stop pushing data into a source, the FG doesn't keep processing until all buffers empty, but I may be wrong.
Thanks again, Adrian On September 17, 2019 3:30:22 PM UTC, Michael Dickens <[email protected]> wrote: >Hi Adrian - To the best of my memory, there is no "flush" or the >equivalent >for clearing buffers after the FG stops but still has residual data in >it. >The best way is to tear the FG down & recreate it; buffers will be >"cleared" in this manner, but it is of course a "hammer" to get the job >done. That said, generally for data streaming a FG won't stop until all >of >the data is pushed through. So if a block isn't somehow processing >data, >then the FG just won't stop & you'll have to kill the FG anyway. I >believe >that for PMT data packets, the FG will stop even if there is residual >PMTs >waiting to be processed ... not 100% sure, but that's my memory ... >because >the data transport is asynchronous & thus harder to track progress. In >data >streaming it's easy to track progress. Hope this is useful! - MLD > >On Tue, Sep 17, 2019 at 3:45 AM Adrian Musceac <[email protected]> >wrote: > >> Thanks Michael, I think this is too complicated for my use case, so >I'll >> find another way. >> Apart from this, is there any way to tell the top block to flush the >> samples still in it after you call stop() and wait()? >> I don't want those samples to be sent out after I call start() again. >> Many thanks, >> >> Adrian >> >> On September 16, 2019 6:23:52 PM UTC, Michael Dickens < >> [email protected]> wrote: >>> >>> Hi Adrian - It's non-trivial to determine the state of the buffers >from >>> inside blocks, but with the correct C++ class/type coercion it can >be done >>> -- even if you're not supposed to do that. I don't recommend doing >so, of >>> course. Thinking there will be a better way to do what you're hoping >to do. >>> - MLD >>> >>> On Mon, Sep 16, 2019 at 11:41 AM Adrian Musceac <[email protected]> >>> wrote: >>> >>>> Hi Kevin, >>>> Thanks for the answer, unfortunately in my case I want to keep the >>>> flowgraph running and I'd need a way to check the state of the >block >>>> buffers. Maybe I can do that with a custom block before the source >or maybe >>>> I should rethink my approach. >>>> >>>> Adrian >>>> >>>> On September 16, 2019 2:42:06 PM UTC, Kevin Reid ><[email protected]> >>>> wrote: >>>>> >>>>> On Mon, Sep 16, 2019 at 4:22 AM Adrian Musceac ><[email protected]> >>>>> wrote: >>>>> >>>>>> So far I haven't found a way (callback?) to tell when the last >sample >>>>>> is out of the flowgraph. I am using the C++ API of GNU radio. >>>>>> >>>>> >>>>> The wait() method of a top_block will block the calling thread >until >>>>> all items have passed through. >>>>> >>>>> Note that this will only succeed if your *source* blocks indicate >>>>> there are no more items, by returning -1 (gr::block::WORK_DONE). >>>>> Vector and file sources and other such standard fixed-length >sources do, >>>>> but if your source is merely emitting no items at this time (e.g. >a network >>>>> source that's not currently receiving packets) the flow graph will >still be >>>>> running waiting for more. I do not know of a way to ask for "when >all >>>>> buffers are currently empty", if that's what you need. >>>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>> >>> >>> -- >>> Michael Dickens, Mac OS X Programmer >>> >>> Ettus Research Technical Support >>> >>> Email: [email protected] >>> >>> Web: http://www.ettus.com >>> >> > >-- >Michael Dickens, Mac OS X Programmer > >Ettus Research Technical Support > >Email: [email protected] > >Web: http://www.ettus.com
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
