On Wed, Apr 2, 2014 at 6:08 PM, Marcus D. Leech <mle...@ripnet.com> 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
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
