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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio