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]
int
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)
consume_each(r);
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,
Marcus
[1]https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/lib/sync_block.cc#L61
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' ?
>
> Thanks
> Franz
>
>
> _______________________________________________
> 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
