We have worked with this block and realized it has a bug (not just an inefficient functionality).
This is easy to see if you consider what happens when the first time work is called, the threshold is passed,
a peak is found in item "i" and so "d_peak_ind" is set to "i",
but there are less that d_lookahead_items to be processed.
Then suppose the second time the work is called, no other peak is found and d_lookahead_remaining goes to 0.
Then the output buffer will be accessed at:
"optr[d_peak_ind] = 1" which may not even be a valid access since the value of d_peak_ind was set to "i"
in the previous work call!
Anyway, I attach a fix to this (we were supposed to post it sooner on the list but got delayed by some other issues).
Please note that in this current form the functionality is a bit different than the one suggested in the manual, ie,
the peak finder ONLY looks ahead d_lookahead items from the point the threshold is crossed, but it does not
reset this window every time a new peak is found within the window.
It should be pretty easy to do this as well...
Please let us know if you have any comments.