if you are implementing an FIR filter using "fast convolution" which uses an FFT and overlap-add or overlap-scrap (often the latter is called "overlap-save"), then the window is *rectangular*, but if you do this right, there is no ripple artifact from the windowing of the time-domain data. none at all.
all overlap-add or overlap-scrap (a.k.a. "overlap-save") is, is a method to make a circular convolution machine perform linear convolution. now, if you're designing your FIR impulse response using the "windowing method", then of course, there are windowing artifacts. i would suggest designing the FIR using the Kaiser window. lastly, it appears to me that you need to get a copy of Oppenhiem and Schafer, because i think you are confusing the overlap-add or overlap-save methods of fast-convolution with the overlap-add method of using STFT for something like a phase vocoder. these two different overlap-adds are not the same thing. -- r b-j r...@audioimagination.com "Imagination is more important than knowledge." > On March 7, 2020 10:42 PM Zhiguang Eric Zhang <zez...@nyu.edu> wrote: > > > Not to threadjack from Alan Wolfe, but the FFT EQ was responsive written in C > and running on a previous gen MacBook Pro from 2011. It wouldn't have been > usable in a DAW even without any UI. It was running FFTW. > > As far as linear / zero-phase, I didn't think about the impulse response but > what you might get are ripple artifacts from the FFT windowing function. > Otherwise the algorithm is inherently zero-phase. > > > On Sat, Mar 7, 2020, 7:11 PM robert bristow-johnson > <r...@audioimagination.com> wrote: > > > > > > > On March 7, 2020 6:43 PM zhiguang zhang <zhiguangezh...@gmail.com> wrote: > > > > > > > > > Yes, essentially you do have the inherent delay involving a window of > > samples in addition to the compute time. > > > > yes. but the compute time is really something to consider as a binary > > decision of whether or not the process can be real time. > > > > assuming your computer can process these samples real time, the delay of > > double-buffering is *twice* the delay of a single buffer or "window" (i > > would not use that term, i might use the term "sample block" or "sample > > frame") of samples. suppose your buffer or sample block is, say, 4096 > > samples. while you are computing your FFT (which is likely bigger than 4K), > > multiplication in the frequency domain, inverse FFT and overlap-adding or > > overlap-scrapping, you are inputting the 4096 samples to be processed for > > your *next* sample frame and you are outputting the 4096 samples of your > > *previous* sample frame. so the entire delay, due to block processing, is > > two frame lengths, in this case, 8192 samples. > > > > now if the processing time required to do the FFT, frequency-domain > > multiplication, iFFT, and overlap-add/scrap exceeds the time of one frame, > > then the process cannot be real time. but if the time required to do all of > > that (including the overhead of interrupt I/O-ing the samples in/out of the > > blocks) is less than that of a frame, the process is or can be made into a > > real-time process and the throughput delay is two frames. > > > > > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote: > > > > ... FFT filtering is essentially zero-phase ... > > > > FFT filtering **can** be linear-phase (which is zero-phase plus a constant > > delay) if the FIR filter impulse response is designed to be linear-phase > > (or symmetrical). it doesn't have to be linear phase. > > > > -- > > > > r b-j r...@audioimagination.com > > > > "Imagination is more important than knowledge." > > > > > On Sat, Mar 7, 2020, 5:40 PM Spencer Russell <s...@media.mit.edu> wrote: > > > > On Sat, Mar 7, 2020, at 6:00 AM, Zhiguang Eric Zhang wrote: > > > > > Traditional FIR/IIR filtering is ubiquitous but actually does suffer > > from drawbacks such as phase distortion and the inherent delay involved. > > FFT filtering is essentially zero-phase, but instead of delays due to > > samples, you get delays due to FFT computational complexity instead. > > > > > > > > I wouldn’t say the delay when using FFT processing is due to > > computational complexity fundamentally. Compute affects your max throughput > > more than your latency. In other words, if you had an infinitely-fast > > computer you would still have to deal with latency. The issue is just that > > you need at least 1 block of input before you can do anything. It’s the > > same thing as with FIR filters, they need to be causal so they can’t be > > zero-phase. In fact you could interchange the FFT processing with a bank of > > FIR band pass filters that you sample from whenever you want to get your > > DFT frame. (that’s basically just a restatement of what I said before about > > the STFT.) > > > > > > > > -s _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
