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
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
