Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

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  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 
>  wrote:
> > 
> >  
> >  > On March 7, 2020 6:43 PM zhiguang zhang  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  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

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

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 
> 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  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=DwIGaQ=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=Rfp1ozFiVA9OFrUgHnk8k4E7erWKoT0p7iI83xAoYEo=PQF0MzrvvmNpczp2_8SZoGEb7ojFOWxu-5BZ5mBpcb0=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[robert bristow-johnson]

> On March 7, 2020 6:43 PM zhiguang zhang  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  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

Re: [music-dsp] FIR blog post & interactive demo

[zhiguang zhang]

Yes, essentially you do have the inherent delay involving a window of
samples in addition to the compute time.

On Sat, Mar 7, 2020, 5:40 PM Spencer Russell  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
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Spencer Russell]

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

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

Sorry I meant Alan :)

On Wed, Jan 15, 2020, 11:20 PM Alan Wolfe  wrote:

> probably pretty basic stuff for most people here but wanted to share a
> writeup and demo i made about FIRs.
>
> Post: https://blog.demofox.org/2020/01/14/fir-audio-data-filters/
> 
> Demo: http://demofox.org/DSPFIR/FIR.html
> 
> Some simple ~175 lines of code C++:
> https://github.com/Atrix256/DSPFIR/blob/master/Source.cpp
> 
> ___
> 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=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=7Qrw7Q-zG9ysrJJyRW6mgLFxHzbEocFKhjiRv2QQvm4=Ny0bCe_dRqaJklgGS5T0Oleuu7EVRRJRYgXtMn6BcIk=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] FIR blog post & interactive demo

[Zhiguang Eric Zhang]

This is a very cool blog, I need to spend some time with it. It's also
interesting to draw parallels between the graphics stuff that Alex writes
about to the audio realm.

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.

On Wed, Mar 4, 2020, 7:56 AM Spencer Russell  wrote:

> On Tue, Mar 3, 2020, at 4:21 PM, robert bristow-johnson wrote:
>
>
> Like a lotta things, sometimes people use the same term to mean something
> different.   A "phase vocoder" (an STFT thing a la Portnoff) is not the
> same as a "channel vocoder" (which is a filter bank thing).
>
>
> It’s maybe worth noting that the STFT _is_ a filter bank where each
> channel is sampled at the hop size and the bandwidth of each band pass
> filter is just the Fourier transform of the windowing function. There’s
> some phase twiddling you can do to convert between a modulated or
> demodulated filter bank.
>
> -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=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=w_CiiFx8eb9uUtrPcg7_DA=wcymP5JMDQ6nmTKKb1JaORXexaD2h-9hKirDMKv6ThY=3MHKW5VQeMC3BYBKg0rjyq0ep3gs4iI56ewvG-XrTMI=
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp