Re: [Discuss-gnuradio] FFT filter bug in GR3.7.4

[Tom Rondeau]

On Wed, Apr 2, 2014 at 6:08 PM, Marcus D. Leech <address@hidden> wrote:

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

Agreed that it's counter intuitive based on experiences with the fir_filters. But that's the difference between the overlap-and-save algorithm that you need to process it a chunk at a time. Unless you want us to put in an internal buffer to store the data while it streams in (which should make Philip jump in here and scream about adding another memory copy operation).

Tom