Hi!
Probably, I have found a bug in the way you create buffers for outgoing
block connections.
First, this is what I have:
A hier-block2, with a gr_block inside, encapsulating some computations.
Inner connections: self.connect(self, ofdm_preamble, self)
where ofdm_preamble is a gr_block of mine.
ofdm_preamble uses set_output_multiple (set to 12) and set_relative_rate
(value: 1.2). The streamsize is 512. It takes 10 vectors, and outputs 12
vectors of size 512 each.
The preceding block is an instance of gr.fft_vcc(). Streamsize is the
same. The IFFT block is connected to the hierarchical block.
Running the system, I get the following:
sched: <gr_block gr_ofdm_preamble (23)> is requesting more input data
than we can provide.
ninput_items_required = 10
max_possible_items_available = 7
If this is a filter, consider reducing the number of taps.
With max_possible_items_available = buf_size-1, the allocated output
buffer of the ifft-block can contain 8 items (vectors).
Now, in
gr_simple_flowgraph_detail::allocate_buffer(…)
you go through each downstream block to ensure that the output buffer is
“at least twice their decimation factor*output_multiple”.
In my situation, ofdm_preamble is the downstream block of ifft-block,
which results in a buffer size of at least 20 (2 * output_multiple *
decimation_factor = 2 * 12 * (1/1.2)).
But, and that’s the bug I suppose (I am not sure about that, since I
didn’t go through all your code), the warning indicates the buffer size
to be 8 items.
I am using Debian. Under Windows/MinGW, everything is fine (I think it’s
due to memory allocation granularity).
Greetings
Dominik