It is physically impossible to build a causal, zero-phase system with non-trivial frequency response.
Ethan > On Mar 7, 2020, at 7: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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.columbia.edu_mailman_listinfo_music-2Ddsp&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=w_CiiFx8eb9uUtrPcg7_DA&m=Rfp1ozFiVA9OFrUgHnk8k4E7erWKoT0p7iI83xAoYEo&s=PQF0MzrvvmNpczp2_8SZoGEb7ojFOWxu-5BZ5mBpcb0&e= > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
