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

Reply via email to