# Re: Notion of buffering up input data in GNURadio

**URL:** <https://www.ruby-forum.com/t/re-notion-of-buffering-up-input-data-in-gnuradio/242085>\
**Category:** GNU Radio\
**Created:** [May 26, 2015, 1:53am UTC](https://www.ruby-forum.com/t/re-notion-of-buffering-up-input-data-in-gnuradio/242085 "2015-05-26T01:53:42Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [May 26, 2015, 1:53am UTC](https://www.ruby-forum.com/t/re-notion-of-buffering-up-input-data-in-gnuradio/242085/1 "2015-05-26T01:53:42Z")

</div>

Hi Marcus,

Thanks for your reply.

> So, you’re writing that application and ask us how your buffering works?  
> that doesn’t sound right, so maybe I’m misunderstanding you?

My bad. What I meant to say was the block that I NEED to implement  
involves a fixed number of samples that I need to collect (as long as  
they  
are  
available) and then start processing those (in my case it is a sliding  
window).

> I think you should really read the guided tutorials I’ve linked to in my  
> last email; you’re trying to replicated functionality that is central to  
> GNU Radio.  
> GNU Radio cares for your block’s in- and output buffers. Unless your  
> work explicitly consumes input items (e.g. by returning a positive  
> number), GNU Radio accumulates the samples in your input buffer.

I have been through most of the tutorials. I merely want to make sure I  
understand  
them right. I do understand you may have answered the same questions  
lots of times before. Apologies for that 🙂

> Don’t you care, GNU Radio does that for you!  
> When your work() is called, GNU Radio knows how many items you can  
> consume (from the input) and how many you can produce (on the output) –

It knows because that is what I specify in the forecast function (for a  
general block)  
am I correct?

> your job as a developer is just writing an algorithm that can work on an  
> array of samples that lies sequentially in memory.

So in my case, if I have a sliding window based avg power calculation  
where  
I first buffer up some samples, then calculate power in each window and  
compare  
it to threshold. If in a particular window power \< threshold, is there  
a  
way to get  
GNURadio to immediately replace that window with new data while I slide  
through  
the rest of the input items?

> If you know how much items you need at once (e.g. you always need 127)  
> you can use set\_output\_multiple (which will inherently set the input  
> multiple on a sync block, i.e. any block with a work(), not a  
> general\_work()), and GNU Radio will only call you if there’s at least  
> 127 items of input.

I understand what you’re saying here.

> Whilst your block is working on its input, new input might already occur  
> from the block upstream – that’s no problem at all (in fact, it’s  
> what’s pretty awesome about the current GNU Radio scheduler). Right  
> after your current work() call is finished (i.e. has "return"ed), work()  
> will be called again, with whatever you left untouched of the input from  
> last time plus the new items.

I also understand this. Only question is like I asked above, is there a  
way  
to update  
new samples in a dynamic way instead of waiting for work to return  
something?  
A case where this might be needed is, if my power never exceeds the  
threshold,  
then nothing will (should) be returned at all.

I am happy to explain further, what i’m trying to implement if  
necessary.

Thanks for your time  
Anil