chjan wrote:In linear mode, the group delay should be constant and (as far as I know) be equal to (N-1)/2, where N = number of taps.
That`s correct in principle, however the implementation in my schematic has a larger delay (1536 samples) because it uses a straight blockwise convolution. With some extra effort (and CP load) the 1024 samples extra latency may be removed (so-called partitioned convolution).
In a DSP algorithm involving recursive feedback with a particular delay (some samples) on the feedback, involving a IIR HP filter, this filter was replaced by Martin's FIR module. The reference is no filter, which by audible inspection has such and such result. The HP filter limits the working area of the feedback loop. (Has to do with acoustic cross talk "elimination", done in the digital domain.
[...]
Unfortunately I don't understand what your goal is there. Is that some known DSP algorithm? Perhaps you have a reference?
Questions:
a) What is the actual delay in samples through this FIR module? (Stating 1024 taps).
1536 samples
b) How linear is the linear version. Is there an inaccuracy here, but perhaps not larger than it could still be called "linear phase"?
I would say it is linear phase within the limits of single precision. You can check by feeding the filter with a single pulse and see that the impulse response is symmetric.
2. Would it be much work to enhance the FIR filter with a user defined number of taps? Because I would like the option to test a "brickwall-ish" HP filter at lower frequencies, e.g. between 100 and 200 Hz, requiring more taps.
I can offer 1024, 2048, 4092 taps etc. User defined filter length would be more work, yes.
3. Not only is this FIR module brilliant in itself, but it also has a proper BODE diagram with logaritmic X scale on "de facto" format. This is very good when comparing results with other software packages, e.g. REW; Room Eq Wisard.
Has someone released such a bode diagram for others to use?
There are Bode diagrams (even including phase) from various sources burried in the forum posts.
4. Has someone released a tool that is good for studying phase and samples delay?
5. I also mention that my (only) problem with Flowstone (latest beta but has been so always) is that as soon as you connect in a plot diagram, then CPU usages raises to unheard levels (+10% cpu on a i7 processor). So if anyone has made (perhaps in Ruby) a plot diagram that does not eat CPU, I would be happy to hear about it. Example: The resulting plot diagram in Martin Vicaneks FIR module is causing +10% cpu, but when removed so that only the "drawing the filter" diagram is left, the cpu drops to 0.5% for a mono signal.
Again, thanks for any response!
Drawing tends to be CPU heavy in FS, but with some care one can often bring it down to acceptable levels. First thing to do is avoid trigger avalanches. Then be reasonable about resolution: how many points do you need? It may help to work with log spaced data. Finally, folks around here can optimize Ruby code. (The FFT analyzer in my schematic is NOT optimized for fast drawing at all).