Hi Marcus,
Thanks for the explanation, it is very clear.
But is there a way to keep track of time elapsed across *consecutive* work calls?
Like I said in the first post in this thread, if I have a sliding window based energy detect. Samples keep coming in, but at some point I will have to say, right I have enough samples, let me start sliding my window now.
My algorithm is, as long signal energy (or power) in each window is less than a threshold, do nothing and keep sliding. The moment power exceeds threshold for the first time, I want to start measuring time. I
need to see how many windows I'm able to slide in the next let's say,
10 milliseconds (because I expect that the actual signal transmission( by which i mean not incoming samples, but *useful* samples) is to last for that long). As a hypothetical example, let's say by 7
milliseconds I've reached the end of the buffer.
My understanding is that by calling forecast, I am effectively creating an an imaginary (?) array of that many samples to process. I may be getting many 100s of samples, but if my forecast says only 50 should dealt with in each work call, then that's how many will be available.
If my understanding
is correct, once I reach the end of this imaginary array, the next set of samples come in (as
per forecast) and work is called again. My question is how do I make
this next work call aware of this concept of time and that 3
milliseconds were unaccounted for in the last call?
Is the solution simply to not limit the number of samples in each work call i.e., not mess around with the forecast function at all?
Thanks
Anil