Hi Laura - All of what's written already is basically correct. I'll add on minor tweak: "ninput_items" and "noutput_items", which are 2 of the arguments to the "work" or "general_work" method, define the maximum number of input and/or output items available to use or requested to produce; see the comments in the header for this method: < https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/include/gnuradio/block.h#L168 >. Which of these variables is used depends on the actual block type as already noted: source, sink, sync, tagged_stream, etc ... for example for a source block -- one that does have inputs -- "ninput_items" is not used; for a sink block "noutput_items" is not used. For general blocks, "ninput_items" is as noted in the header: "number of input items available on each input stream", and "noutput_items" is "number of output items to write on each output stream" ... but note that both of these are maximums. The values of these variables generally varies during runtime -- or rather, it is not guaranteed that they will constant -- so, you can't do something like "always produce 100 items", because there might not be enough output buffer space. Hence you have to rely on the values of these variables to determine how to do "work", and needs to keep track of the number of items consumed during work (and then consume just that number). Hopefully this and the other replies provide enough information for you to figure out how to proceed. Cheers! - MLD
ps> It is -very- cool to have a neuroengineer and anesthesiologist using GR! On Fri, Aug 30, 2019 at 6:27 AM Albin Stigö <albin.st...@gmail.com> wrote: > Laura et al, > > consume_each <= ninput_items. > > If you need a larger buffer than you consume you can abuse the > scheduler slightly by set_relative_rate(1, some_min_input_items), this > is done in the stream to vector blocks for example. I do this in a > visualization sink where I need to produce FFTs with a certain > overlap. > > // We need at least this number of points to do our job > m_input_length = std::max<int>(m_consume_each, m_fft_size); > // This is probably abusing the scheduler quite a bit > set_relative_rate(1, m_input_length); > > Interesting to see you work in neuroengineering. I'm an > anesthesiologist and very interested these applications of gnuradio. > > > --Albin > > On Fri, Aug 30, 2019 at 11:44 AM Marcus Müller <mmuel...@gnuradio.org> > wrote: > > > > Hi Laura, > > > > the buffer sizes are determined at flow graph startup based on the > > involved block's io signature, output multiples, alignment > > requirements, minimum and maximum buffer sizes, and the page size > > (which practically everywhere is 4kB). > > > > I think you're expecting the amount of items your block is presented > > with to be deterministic: it's simply not. > > > > It's a thing that depends on the temporal execution of the signal > > processing flowgraph at run time. Thus, your work (or general_work) > > must always make sure it works within the boundaries of how many > > samples are supplied in that specific call, and how much output space > > is available at that point. > > > > I think > > > > https://www.gnuradio.org/blog/2017-01-05-buffers/ > > > > might be of interest to you. > > > > Best regards, > > Marcus > > > > On Thu, 2019-08-29 at 14:27 -0700, Laura Arjona wrote: > > > Thank you very much Michael. > > > > > > What are the I/O buffer sizes? > > > > > > * My block is a general block > > > * In my forecast: ninput_items_required[0] = noutput_items; > > > * In the general_work: const gr_complex *in = (const gr_complex *) > > > input_items[0]; > > > float *out = (float *) > > > output_items[0]; > > > > > > /* > > > * The private constructor > > > */ > > > decoder_impl::frame_decoder_impl(int sample_rate,std::vector<int> > > > output_sizes) > > > : gr::block("decoder", > > > gr::io_signature::make(1, 1, sizeof(gr_complex)), > > > gr::io_signature::makev(2, 2, output_sizes)), > > > s_rate(sample_rate) > > > { > > > > > > > > > > > > > > > On Thu, Aug 29, 2019 at 5:41 AM Michael Dickens < > > > michael.dick...@ettus.com> wrote: > > > > Hi Laura - In the "work" or "general_work" method, there are > > > > arguments that contain the information you're looking for. These > > > > arguments are set depending on what type of block you're creating > > > > (source, sink, sync, tagged_stream, whatever), are influenced by > > > > what the "forecast()" method returns, and are constrained by the > > > > I/O buffer sizes. Sorry to be a little vague, but the answer is > > > > that the value of the variable "consumed" in your description is > > > > context dependent. Hope this is useful! - MLD > > > > > > > > On Wed, Aug 28, 2019 at 2:53 PM Laura Arjona <arjo...@uw.edu> > > > > wrote: > > > > > Hello GNURadio community, > > > > > > > > > > Does anyone know what is the maximum number of input items that > > > > > an Out Of Tree block can consume on each input stream? > > > > > > > > > > consume_each(consumed) --> what is the maximum value that the > > > > > variable consumed can take? > > > > > > > > > > Thank you very much. > > > > > > > > > > > > > > > -- > > > > > Laura Arjona > > > > > Washington Research Foundation Innovation Postdoctoral Fellow in > > > > > Neuroengineering > > > > > > > > > > Paul G. Allen School of Computer Science & Engineering > > > > > 185 E Stevens Way NE > > > > > University of Washington > > > > > Seattle, WA 98195-2350 > > > > > _______________________________________________ > > > > > Discuss-gnuradio mailing list > > > > > Discuss-gnuradio@gnu.org > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > > > -- > > > > Michael Dickens, Mac OS X Programmer > > > > > > > > Ettus Research Technical Support > > > > > > > > Email: supp...@ettus.com > > > > > > > > Web: http://www.ettus.com > > > > > > > > > _______________________________________________ > > > Discuss-gnuradio mailing list > > > Discuss-gnuradio@gnu.org > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Michael Dickens, Mac OS X Programmer Ettus Research Technical Support Email: supp...@ettus.com Web: http://www.ettus.com
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
