[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] OOT Blocklength

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] OOT Blocklength
Date: Sat, 21 May 2016 19:58:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Hey Franz,

most sources are implemented as sync blocks, too! So you just produce up to noutput_items.

So to give you a bit of background:

GNU Radio blocks have output buffers that are circular, ie. through "clever" memory mapping, they seem to continue after the last item with the first item. That means that an "upstream" block can fill that buffer, while a downstream block reads that buffer, every (general_)work call. noutput_items is not really your "block size", it's the amount of free space in your output buffer.

GNU Radio calls your block's "general_work" method whenever there's new space in the output buffer or new input available; it first asks the "forecast" method
"hey, I'd like you to produce N output items. Could you please tell me how much input on the individual input streams you need?"
The forecast method might tell GNU Radio that it needs a lot of input, even more than is currently available in the output buffer of the upstream block. The scheduler reduces (typically: halves) the number of output items it asks for, and calls forecast again, and so on.

After the scheduler has found a number N small enough so that the block can work with the input that's actually available, the "general_work" gets called with that input, and is asked to produce up to noutput_items output; noutput_items might actually be more than the block can produce, but it's really just how much output the block is asked to produce. The number of items that call to general_work actually produces is normally determined by returning an integer, which must be <= noutput_items. The number of items on the input buffer(s) that have been processed ("consumed") is determined by calling the "consume" (or "consume_each") method with that number.

Sync blocks are only special because they are subclasses of the "normal blocks", in which a forecast method is already defined (so you don't have to implement that) which always tells them "OK, for N output, I'll need N input".
Also, the sync block implements a "general_work" that actually does little more than calling a "work" method – with one parameter less than the general_work, because we know how much input will be relevant – exactly the amount of output requested, noutput_items (if there's more input than output space, you can't consume all the input, if there's more output space than input, then forecast will tell the scheduler we can't produce that much). Also, since the return value of the work() method is the number of samples produced, and for a sync block that is identical to the number of items consumed, a sync block's general_work is really only[1]

  sync_block::general_work(int noutput_items,
                           gr_vector_int &ninput_items,
                           gr_vector_const_void_star &input_items,
                           gr_vector_void_star &output_items)
    int r = work(noutput_items, input_items, output_items);
    if(r > 0)
    return r;

as you can see, work is really just general work, reduced by the ninput_items parameter, because ninput_items must be >=noutput_items (otherwise, it wouldn't be called), and that is the maximum amount of items that your work might produce.

So, what about sources?
Sources are really sync blocks with 0 input streams; so there's "always" enough input (because you can't have any, anyways), and the only limiting factor for the amount of items produced in a call to work is the amount of free space in the output buffer.

So, make sure you produce up to noutput_items items in your source's work by writing them into the output buffer (output_items[]), and return the actual number of items you've written that way; again: that might be less than noutput_items.

Best regards,

On 21.05.2016 12:37, Franz Dworschak wrote:
Hey all,

In synchronous OOT blocks or sinks the length is defined by the system, because I get the parameter noutput_items, but when I have a source, which block size should be used ?
And how does the system 'know' how many memory it should reserve ?
I tried sending one data value each call, but this reduced the maximum sample rate below 100ks. With 256 data words it works, but is that 'good' ?


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]