On Sun, Feb 27, 2005 at 11:22:53AM +1030, Daniel O'Connor wrote: > On Sun, 27 Feb 2005 05:04, Eric Blossom wrote: > > > You'd be depending on unspecified and HIGHLY subject-to-change > > implementation details. If you are counting on a delay and a parallel > > filter to stay in phase, they need to be implemented in the same C++ > > block. We don't make any guarantees about the amount of buffering > > between blocks and whether it stays constant over time. > > > > Is this a scary enough disclaimer? > > Ahh right, I didn't realise the buffering between blocks was allowed to > change..
FYI, my disclaimer was probably a bit over the top. I'm not trying to break anything that works, but I do want to leave us some implementation flexibility for the future. It's unlikely that the buffering would change at runtime unless your application changed something such as number of taps in a filter, amount of "history" for a particular block, change in interpolation or decimation factors, etc. All that said, in the particular case of a delay line in parallel with a filter, the safe answer is a general block that pairs the filter with a delay line. Eric _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
