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