it is not causal because the zero-phase system does not depend on past samples
On Sun, Mar 8, 2020 at 1:58 PM Zhiguang Eric Zhang <zez...@nyu.edu> wrote: > the frequency response is a function of the windowing function > > On Sun, Mar 8, 2020 at 10:34 AM robert bristow-johnson < > r...@audioimagination.com> wrote: > >> >> >> > On March 8, 2020 10:05 AM Ethan Duni <ethan.d...@gmail.com> wrote: >> > >> > >> > It is physically impossible to build a causal, zero-phase system with >> non-trivial frequency response. >> >> a system that operates in real time. when processing sound files you can >> pretend that you're looking at some "future" samples. i guess that would >> be acausal, so you're right, Ethan. >> >> -- >> >> r b-j r...@audioimagination.com >> >> "Imagination is more important than knowledge." >> >> >> > >> > > 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=saJ0IC40JGWeOGaONJ6jTXPSJtWmpzejoo8nX3eSWs8&s=WXWL91lRoTbvxjpEmSd4HWZBuRlfWGw7fwG4xVWHIvI&e= > >
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
