That's actually not surprising. The buffer is established when the
top_block is started and will be based on the size of the FFT you need
to run. Increasing the size of the filter will not increase the size
of the buffer. We'll have to figure out how we want the solution to
this to look. Might be we just refuse to increase the filter size
during runtime so you'll have to lock/unlock the flowgraph. Will think
more on this...
Tom
It's counter to the experience with the regular dot-product FIR filters
in that you can re-size them at runtime and it's just fine. It
certainly fails the
"least astonishment" test when you have a filter that's configured
for "pass-through" (1+0j single tap) and then later ask it to do some real
filtering.
But this bug has been around for a long time, as I was reminded. My
other code has "hacks" to get around this, and when I was re-structuring
for migration to GR3.7, it reared its unpleasant little head again.
Granted, my use case, in this case, is a bit weird--the filter can go
from "passthrough" to "farking massive" in one swell foop, when the user
turns on coherent dedispersion and suddenly that's a rather-large
de-dispersion filter in the path.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
