Re: [music-dsp] FIR blog post & interactive demo
On Sun, Mar 8, 2020 at 8:02 PM Spencer Russell wrote: > In fact, the the standard STFT analysis/synthesis pipeline is the same > thing as overlap-add "fast convolution" if you: > > 1. Use a rectangular window with a length equal to your hop size > 2. zero-pad each input frame by the length of your FIR kernel minus 1 > Indeed, the two ideas are closely related and can be combined. It's more a difference in the larger approach. If you can specify the desired response in terms of an FIR of some fixed length, then you can account for the circular effects and use fast FIR. Note that this is a time-variant MIMO system constructed to be equivalent to a time-invariant SISO system (modulo finite word length effects, as you say). Alternatively, the desired response can be specified in the STFT domain. This comes up naturally in situations where it is estimated in the frequency domain to begin with, such as noise suppression or channel equalization. Then, circular convolution effects are controlled through a combination of pre/post windowing and smoothing/conditioning of the frequency response. Unlike the fast FIR case, the time-variant effects are only approximately suppressed: this is a time-variant MIMO system that is *not* equivalent to any time-invariant SISO system. So there is an extra layer of engineering needed in STFT systems to ensure that time domain aliasing is adequately suppressed. With fast FIR, you just calculate the correct size to zero-pad (or delete), and then there is no aliasing to worry about. Ethan ___ 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
Nowhere was it mentioned that there was an across the frame multiplication with a scalar as far as manipulating the transform coefficients. That might make it time variant. My concept was in the domain of audio engineering which reads a side-chain signal to obtain attenuation factors in the context of EQ. Please see the Wavesfactory Trackspacer to get a sense of what I mean. On Sun, Mar 8, 2020, 11:02 PM Spencer Russell wrote: > On Sun, Mar 8, 2020, at 7:41 PM, Ethan Duni wrote: > > FFT filterbanks are time variant due to framing effects and the circular > convolution property. They exhibit “perfect reconstruction” if you design > the windows correctly, but this only applies if the FFT coefficients are > not altered between analysis and synthesis. If you alter the FFT > coefficients (i.e., “filtering”), it causes time domain aliasing. > > > But you can avoid this by zero-padding before you do the FFT. In effect > this turns circular convolution into linear convolution - the "tail" ends > up in the zero-pading rather than wrapping around and causing > time-aliasing. This is what overlap-add FFT convolution does. > > In fact, the the standard STFT analysis/synthesis pipeline is the same > thing as overlap-add "fast convolution" if you: > > 1. Use a rectangular window with a length equal to your hop size > 2. zero-pad each input frame by the length of your FIR kernel minus 1 > > Then the regular overlap-add STFT resynthesis is the same as "fast > convolution", and will give you the same thing (to numerical precision) you > would get with a time-domain FIR implementation. > > On Mar 8, 2020, at 2:04 PM, zhiguang zhang > wrote: > > but bringing up traditional FIR/IIR filtering terminology to describe FFT > filtering doesn't make sense in my mind. I'm not in the audio field. but > yes, I do believe that the system is time invariant, but I don't have time > to prove myself to you on this forum at this time, nor do I have any > interest in meeting Dr Bosi at AES. > > > I don't really understand this perspective - there's a tremendous amount > of conceptual overlap between these ideas, and regimes where they are > completely equivalent (e.g. implementing a time-invariant FIR filter in the > frequency domain using block-by-block "fast convolution"). Certainly when > you're doing time-variant filtering things are somewhat different (e.g. > multiplying in the STFT domain with changing coefficients is doing some > kind of frame-by-frame cross-fading, which will not give the same result as > varying the parameters of an FIR filter on a sample-by-sample basis, in a > pure time-domain implementation). That said, using the same terminology > where we can helps highlight the places where these concepts are related. > > -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
On Sun, Mar 8, 2020, at 7:41 PM, Ethan Duni wrote: > FFT filterbanks are time variant due to framing effects and the circular > convolution property. They exhibit “perfect reconstruction” if you design the > windows correctly, but this only applies if the FFT coefficients are not > altered between analysis and synthesis. If you alter the FFT coefficients > (i.e., “filtering”), it causes time domain aliasing. But you can avoid this by zero-padding before you do the FFT. In effect this turns circular convolution into linear convolution - the "tail" ends up in the zero-pading rather than wrapping around and causing time-aliasing. This is what overlap-add FFT convolution does. In fact, the the standard STFT analysis/synthesis pipeline is the same thing as overlap-add "fast convolution" if you: 1. Use a rectangular window with a length equal to your hop size 2. zero-pad each input frame by the length of your FIR kernel minus 1 Then the regular overlap-add STFT resynthesis is the same as "fast convolution", and will give you the same thing (to numerical precision) you would get with a time-domain FIR implementation. >> On Mar 8, 2020, at 2:04 PM, zhiguang zhang wrote: >> but bringing up traditional FIR/IIR filtering terminology to describe FFT >> filtering doesn't make sense in my mind. I'm not in the audio field. but >> yes, I do believe that the system is time invariant, but I don't have time >> to prove myself to you on this forum at this time, nor do I have any >> interest in meeting Dr Bosi at AES. I don't really understand this perspective - there's a tremendous amount of conceptual overlap between these ideas, and regimes where they are completely equivalent (e.g. implementing a time-invariant FIR filter in the frequency domain using block-by-block "fast convolution"). Certainly when you're doing time-variant filtering things are somewhat different (e.g. multiplying in the STFT domain with changing coefficients is doing some kind of frame-by-frame cross-fading, which will not give the same result as varying the parameters of an FIR filter on a sample-by-sample basis, in a pure time-domain implementation). That said, using the same terminology where we can helps highlight the places where these concepts are related. -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
so Ethan, what is your definition of time invariance? because you say it's not time invariant because of time domain aliasing but then you say there is delay due to compute time. delay due to window and compute time is unavoidable and not to be factored into time invariance / variance. coding noise is to due quantization and actually the fact that coefficients themselves are changed, because you have to decompose the digital signal from, say, a cello string recording. when you digitally alter the transform coefficients, you get coding noise, which is unavoidable. perfect reconstruction is purely theoretical and also mathematically rigorous. On Sun, Mar 8, 2020 at 7:51 PM Ethan Duni wrote: > No, MDCT TDAC is the same. Perfect reconstruction only obtains if the > coefficients are not changed at all. Coding noise causes (uncancelled) time > domain aliasing that is shaped according to the window design. Limiting > this effect is a primary aspect of MDCT codec design. > > Ethan > > On Mar 8, 2020, at 4:45 PM, zhiguang zhang > wrote: > > > Audio compression by definition 'alters' the transform coefficients and > they get perfect reconstruction with no aliasing due to the transform > alone. In fact 'TDAC' or time domain aliasing cancellation is a hallmark > of the MDCT or DCT type IV which is ubiquitous in audio codecs. > > On Sun, Mar 8, 2020, 7:41 PM Ethan Duni wrote: > >> FFT filterbanks are time variant due to framing effects and the circular >> convolution property. They exhibit “perfect reconstruction” if you design >> the windows correctly, but this only applies if the FFT coefficients are >> not altered between analysis and synthesis. If you alter the FFT >> coefficients (i.e., “filtering”), it causes time domain aliasing. >> >> So, the operation of such a system can’t be reduced down to an equivalent >> LTI frequency response. We have the more basic issue of limiting the >> aliasing to acceptable levels. This depends partially on the frame size, >> overlap, and window shape, as these determine how any aliasing is >> distributed in a time/frequency sense. But more fundamentally, you have to >> put constraints on the response curves to limit the aliasing. I.e. the >> steeper the transitions in the frequency response, the longer the implied >> impulse response, and so the time domain aliasing gets worse. >> >> It is certainly possible to run any filter bank offline and compensate >> for its latency, in order to get a “zero phase” processing. But >> fundamentally they have framing delay given by the frame size, and >> algorithmic latency given by the overlap. These are the delays that you’d >> compensate when running offline. >> >> Ethan >> >> On Mar 8, 2020, at 2:04 PM, zhiguang zhang >> wrote: >> >> >> The system is memoryless just because it is based on the DFT and nothing >> else, which is also why it's time-invariant. unless you alter certain >> parameters in real-time like the window size or hop size or windowing >> function, etc, any input gives you the same output at any given time, which >> is the definition of time-invariance. >> >> well, you're RBJ and I see that you used to work at Kurzweil until 2008. >> that's cool and what have you been up to since then? incidentally i was in >> California until 2008. >> >> As you might be able to tell, i don't care too much about the fact that >> time domain filtering theory is brought up often because I did my master's >> thesis with this frequency domain FFT filter, which I believe was rather >> novel at the time of completion. I do know that the field is steeped in >> tradition, which might be why I'm writing to the mailing list and to you in >> particular. but bringing up traditional FIR/IIR filtering terminology to >> describe FFT filtering doesn't make sense in my mind. I'm not in the audio >> field. but yes, I do believe that the system is time invariant, but I >> don't have time to prove myself to you on this forum at this time, nor do I >> have any interest in meeting Dr Bosi at AES. >> >> -ez >> >> >> >> On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson < >> r...@audioimagination.com> wrote: >> >>> >>> >>> > On March 8, 2020 3:07 PM zhiguang zhang >>> wrote: >>> > >>> > >>> > Well I believe the system is LTI just because the DFT is LTI by >>> definition. >>> >>> TI is nowhere in the definition of the DFT. L is a consequence of the >>> definition of the DFT, but the DFT is not an LTI system. it is an >>> operation done to a finite segment of samples of a discrete-time signal. >>> >>> > The impulse response of a rectangular window I believe is that of a >>> sinc function, >>> >>> window functions do not have impulse responses. >>> >>> both window functions and impulse responses can be Fourier transformed. >>> the Fourier transform of the latter is what we call the "frequency >>> response" of the system. i am not sure what they call the fourier >>> transform of a window function. what is done with the frequency response
Re: [music-dsp] FIR blog post & interactive demo
> > If the system is suitably designed (e.g. correct window and overlap), > you can filter using an FFT and get identical results to a time domain > FIR filter (up-to rounding/precision limits, of course). The > appropriate window and overlap process will cause all circular > convolution artefacts to cancel. Fast FIR is a different thing than an FFT filter bank. You can combine the two approaches but I don’t think that’s what is being done here? Ethan ___ 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
On Sun, Mar 8, 2020 at 11:41 PM Ethan Duni wrote: > FFT filterbanks are time variant due to framing effects and the circular > convolution property. They exhibit “perfect reconstruction” if you design the > windows correctly, but this only applies if the FFT coefficients are not > altered between analysis and synthesis. If you alter the FFT coefficients > (i.e., “filtering”), it causes time domain aliasing. If the system is suitably designed (e.g. correct window and overlap), you can filter using an FFT and get identical results to a time domain FIR filter (up-to rounding/precision limits, of course). The appropriate window and overlap process will cause all circular convolution artefacts to cancel. In fact, one particularly computationally efficient method to apply a very long FIR filter (e.g. for reverbs) with low delay is to factor it into a low delay portion and one or more longer delay chunks and use naive convolution for the low delay portion and large overlapped FFTs for the high delay portions. ___ 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
No, MDCT TDAC is the same. Perfect reconstruction only obtains if the coefficients are not changed at all. Coding noise causes (uncancelled) time domain aliasing that is shaped according to the window design. Limiting this effect is a primary aspect of MDCT codec design. Ethan > On Mar 8, 2020, at 4:45 PM, zhiguang zhang wrote: > > > Audio compression by definition 'alters' the transform coefficients and they > get perfect reconstruction with no aliasing due to the transform alone. In > fact 'TDAC' or time domain aliasing cancellation is a hallmark of the MDCT or > DCT type IV which is ubiquitous in audio codecs. > >> On Sun, Mar 8, 2020, 7:41 PM Ethan Duni wrote: >> FFT filterbanks are time variant due to framing effects and the circular >> convolution property. They exhibit “perfect reconstruction” if you design >> the windows correctly, but this only applies if the FFT coefficients are not >> altered between analysis and synthesis. If you alter the FFT coefficients >> (i.e., “filtering”), it causes time domain aliasing. >> >> So, the operation of such a system can’t be reduced down to an equivalent >> LTI frequency response. We have the more basic issue of limiting the >> aliasing to acceptable levels. This depends partially on the frame size, >> overlap, and window shape, as these determine how any aliasing is >> distributed in a time/frequency sense. But more fundamentally, you have to >> put constraints on the response curves to limit the aliasing. I.e. the >> steeper the transitions in the frequency response, the longer the implied >> impulse response, and so the time domain aliasing gets worse. >> >> It is certainly possible to run any filter bank offline and compensate for >> its latency, in order to get a “zero phase” processing. But fundamentally >> they have framing delay given by the frame size, and algorithmic latency >> given by the overlap. These are the delays that you’d compensate when >> running offline. >> >> Ethan >> On Mar 8, 2020, at 2:04 PM, zhiguang zhang wrote: >>> >>> The system is memoryless just because it is based on the DFT and nothing >>> else, which is also why it's time-invariant. unless you alter certain >>> parameters in real-time like the window size or hop size or windowing >>> function, etc, any input gives you the same output at any given time, which >>> is the definition of time-invariance. >>> >>> well, you're RBJ and I see that you used to work at Kurzweil until 2008. >>> that's cool and what have you been up to since then? incidentally i was in >>> California until 2008. >>> >>> As you might be able to tell, i don't care too much about the fact that >>> time domain filtering theory is brought up often because I did my master's >>> thesis with this frequency domain FFT filter, which I believe was rather >>> novel at the time of completion. I do know that the field is steeped in >>> tradition, which might be why I'm writing to the mailing list and to you in >>> particular. but bringing up traditional FIR/IIR filtering terminology to >>> describe FFT filtering doesn't make sense in my mind. I'm not in the audio >>> field. but yes, I do believe that the system is time invariant, but I >>> don't have time to prove myself to you on this forum at this time, nor do I >>> have any interest in meeting Dr Bosi at AES. >>> >>> -ez >>> >>> >>> On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson wrote: > On March 8, 2020 3:07 PM zhiguang zhang wrote: > > > Well I believe the system is LTI just because the DFT is LTI by > definition. TI is nowhere in the definition of the DFT. L is a consequence of the definition of the DFT, but the DFT is not an LTI system. it is an operation done to a finite segment of samples of a discrete-time signal. > The impulse response of a rectangular window I believe is that of a sinc > function, window functions do not have impulse responses. both window functions and impulse responses can be Fourier transformed. the Fourier transform of the latter is what we call the "frequency response" of the system. i am not sure what they call the fourier transform of a window function. what is done with the frequency response (multiplication) is *not* what is done with the fourier transform of a window function (convolution). > which has ripple artifacts. there are no ripple artifacts in fast convolution using a rectangular window. you need to learn what that is. > Actually, the overlap-add method (sorry I don't have time to dig into > the differences between overlap-add and overlap-save right now) what you need is time to learn the basics and learn the proper terminology of things so that confusion in communication is minimum. > minimizes artifacts
Re: [music-dsp] FIR blog post & interactive demo
Audio compression by definition 'alters' the transform coefficients and they get perfect reconstruction with no aliasing due to the transform alone. In fact 'TDAC' or time domain aliasing cancellation is a hallmark of the MDCT or DCT type IV which is ubiquitous in audio codecs. On Sun, Mar 8, 2020, 7:41 PM Ethan Duni wrote: > FFT filterbanks are time variant due to framing effects and the circular > convolution property. They exhibit “perfect reconstruction” if you design > the windows correctly, but this only applies if the FFT coefficients are > not altered between analysis and synthesis. If you alter the FFT > coefficients (i.e., “filtering”), it causes time domain aliasing. > > So, the operation of such a system can’t be reduced down to an equivalent > LTI frequency response. We have the more basic issue of limiting the > aliasing to acceptable levels. This depends partially on the frame size, > overlap, and window shape, as these determine how any aliasing is > distributed in a time/frequency sense. But more fundamentally, you have to > put constraints on the response curves to limit the aliasing. I.e. the > steeper the transitions in the frequency response, the longer the implied > impulse response, and so the time domain aliasing gets worse. > > It is certainly possible to run any filter bank offline and compensate for > its latency, in order to get a “zero phase” processing. But fundamentally > they have framing delay given by the frame size, and algorithmic latency > given by the overlap. These are the delays that you’d compensate when > running offline. > > Ethan > > On Mar 8, 2020, at 2:04 PM, zhiguang zhang > wrote: > > > The system is memoryless just because it is based on the DFT and nothing > else, which is also why it's time-invariant. unless you alter certain > parameters in real-time like the window size or hop size or windowing > function, etc, any input gives you the same output at any given time, which > is the definition of time-invariance. > > well, you're RBJ and I see that you used to work at Kurzweil until 2008. > that's cool and what have you been up to since then? incidentally i was in > California until 2008. > > As you might be able to tell, i don't care too much about the fact that > time domain filtering theory is brought up often because I did my master's > thesis with this frequency domain FFT filter, which I believe was rather > novel at the time of completion. I do know that the field is steeped in > tradition, which might be why I'm writing to the mailing list and to you in > particular. but bringing up traditional FIR/IIR filtering terminology to > describe FFT filtering doesn't make sense in my mind. I'm not in the audio > field. but yes, I do believe that the system is time invariant, but I > don't have time to prove myself to you on this forum at this time, nor do I > have any interest in meeting Dr Bosi at AES. > > -ez > > > > On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson < > r...@audioimagination.com> wrote: > >> >> >> > On March 8, 2020 3:07 PM zhiguang zhang >> wrote: >> > >> > >> > Well I believe the system is LTI just because the DFT is LTI by >> definition. >> >> TI is nowhere in the definition of the DFT. L is a consequence of the >> definition of the DFT, but the DFT is not an LTI system. it is an >> operation done to a finite segment of samples of a discrete-time signal. >> >> > The impulse response of a rectangular window I believe is that of a >> sinc function, >> >> window functions do not have impulse responses. >> >> both window functions and impulse responses can be Fourier transformed. >> the Fourier transform of the latter is what we call the "frequency >> response" of the system. i am not sure what they call the fourier >> transform of a window function. what is done with the frequency response >> (multiplication) is *not* what is done with the fourier transform of a >> window function (convolution). >> >> > which has ripple artifacts. >> >> there are no ripple artifacts in fast convolution using a rectangular >> window. you need to learn what that is. >> >> > Actually, the overlap-add method (sorry I don't have time to dig into >> the differences between overlap-add and overlap-save right now) >> >> what you need is time to learn the basics and learn the proper >> terminology of things so that confusion in communication is minimum. >> >> > minimizes artifacts depending on the windowing function. >> >> again, there are no ripple artifacts in fast convolution using a >> rectangular window. none whatsoever. >> >> > A sine window ... >> >> i think you might mean the "Hann window" (sometimes misnamed "Hanning", >> but that is an old misnomer). i have never heard of a "sine window" and i >> have been doing this for 45 years. perhaps the classic Fred Harris paper >> on windows has a "sine window". >> >> > ... actually sums to 1, >> >> that's what we mean by "complementary". >> >> > the proof of which can be found in audio
Re: [music-dsp] FIR blog post & interactive demo
FFT filterbanks are time variant due to framing effects and the circular convolution property. They exhibit “perfect reconstruction” if you design the windows correctly, but this only applies if the FFT coefficients are not altered between analysis and synthesis. If you alter the FFT coefficients (i.e., “filtering”), it causes time domain aliasing. So, the operation of such a system can’t be reduced down to an equivalent LTI frequency response. We have the more basic issue of limiting the aliasing to acceptable levels. This depends partially on the frame size, overlap, and window shape, as these determine how any aliasing is distributed in a time/frequency sense. But more fundamentally, you have to put constraints on the response curves to limit the aliasing. I.e. the steeper the transitions in the frequency response, the longer the implied impulse response, and so the time domain aliasing gets worse. It is certainly possible to run any filter bank offline and compensate for its latency, in order to get a “zero phase” processing. But fundamentally they have framing delay given by the frame size, and algorithmic latency given by the overlap. These are the delays that you’d compensate when running offline. Ethan > On Mar 8, 2020, at 2:04 PM, zhiguang zhang wrote: > > > The system is memoryless just because it is based on the DFT and nothing > else, which is also why it's time-invariant. unless you alter certain > parameters in real-time like the window size or hop size or windowing > function, etc, any input gives you the same output at any given time, which > is the definition of time-invariance. > > well, you're RBJ and I see that you used to work at Kurzweil until 2008. > that's cool and what have you been up to since then? incidentally i was in > California until 2008. > > As you might be able to tell, i don't care too much about the fact that time > domain filtering theory is brought up often because I did my master's thesis > with this frequency domain FFT filter, which I believe was rather novel at > the time of completion. I do know that the field is steeped in tradition, > which might be why I'm writing to the mailing list and to you in particular. > but bringing up traditional FIR/IIR filtering terminology to describe FFT > filtering doesn't make sense in my mind. I'm not in the audio field. but > yes, I do believe that the system is time invariant, but I don't have time to > prove myself to you on this forum at this time, nor do I have any interest in > meeting Dr Bosi at AES. > > -ez > > > >> On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson >> wrote: >> >> >> > On March 8, 2020 3:07 PM zhiguang zhang wrote: >> > >> > >> > Well I believe the system is LTI just because the DFT is LTI by definition. >> >> TI is nowhere in the definition of the DFT. L is a consequence of the >> definition of the DFT, but the DFT is not an LTI system. it is an operation >> done to a finite segment of samples of a discrete-time signal. >> >> > The impulse response of a rectangular window I believe is that of a sinc >> > function, >> >> window functions do not have impulse responses. >> >> both window functions and impulse responses can be Fourier transformed. the >> Fourier transform of the latter is what we call the "frequency response" of >> the system. i am not sure what they call the fourier transform of a window >> function. what is done with the frequency response (multiplication) is >> *not* what is done with the fourier transform of a window function >> (convolution). >> >> > which has ripple artifacts. >> >> there are no ripple artifacts in fast convolution using a rectangular >> window. you need to learn what that is. >> >> > Actually, the overlap-add method (sorry I don't have time to dig into the >> > differences between overlap-add and overlap-save right now) >> >> what you need is time to learn the basics and learn the proper terminology >> of things so that confusion in communication is minimum. >> >> > minimizes artifacts depending on the windowing function. >> >> again, there are no ripple artifacts in fast convolution using a rectangular >> window. none whatsoever. >> >> > A sine window ... >> >> i think you might mean the "Hann window" (sometimes misnamed "Hanning", but >> that is an old misnomer). i have never heard of a "sine window" and i have >> been doing this for 45 years. perhaps the classic Fred Harris paper on >> windows has a "sine window". >> >> > ... actually sums to 1, >> >> that's what we mean by "complementary". >> >> > the proof of which can be found in audio coding theory. I suggest you >> > check out the book by Bosi. >> >> i didn't even know Marina did a book, but i am not surprized. i've known >> (or been acquainted with) Marina since she was with Digidesign back in the >> early 90s. before the Dolby Lab days. before her injury at the New York >> Hilton in 1993. would
Re: [music-dsp] FIR blog post & interactive demo
The system is memoryless just because it is based on the DFT and nothing else, which is also why it's time-invariant. unless you alter certain parameters in real-time like the window size or hop size or windowing function, etc, any input gives you the same output at any given time, which is the definition of time-invariance. well, you're RBJ and I see that you used to work at Kurzweil until 2008. that's cool and what have you been up to since then? incidentally i was in California until 2008. As you might be able to tell, i don't care too much about the fact that time domain filtering theory is brought up often because I did my master's thesis with this frequency domain FFT filter, which I believe was rather novel at the time of completion. I do know that the field is steeped in tradition, which might be why I'm writing to the mailing list and to you in particular. but bringing up traditional FIR/IIR filtering terminology to describe FFT filtering doesn't make sense in my mind. I'm not in the audio field. but yes, I do believe that the system is time invariant, but I don't have time to prove myself to you on this forum at this time, nor do I have any interest in meeting Dr Bosi at AES. -ez On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson < r...@audioimagination.com> wrote: > > > > On March 8, 2020 3:07 PM zhiguang zhang > wrote: > > > > > > Well I believe the system is LTI just because the DFT is LTI by > definition. > > TI is nowhere in the definition of the DFT. L is a consequence of the > definition of the DFT, but the DFT is not an LTI system. it is an > operation done to a finite segment of samples of a discrete-time signal. > > > The impulse response of a rectangular window I believe is that of a sinc > function, > > window functions do not have impulse responses. > > both window functions and impulse responses can be Fourier transformed. > the Fourier transform of the latter is what we call the "frequency > response" of the system. i am not sure what they call the fourier > transform of a window function. what is done with the frequency response > (multiplication) is *not* what is done with the fourier transform of a > window function (convolution). > > > which has ripple artifacts. > > there are no ripple artifacts in fast convolution using a rectangular > window. you need to learn what that is. > > > Actually, the overlap-add method (sorry I don't have time to dig into > the differences between overlap-add and overlap-save right now) > > what you need is time to learn the basics and learn the proper terminology > of things so that confusion in communication is minimum. > > > minimizes artifacts depending on the windowing function. > > again, there are no ripple artifacts in fast convolution using a > rectangular window. none whatsoever. > > > A sine window ... > > i think you might mean the "Hann window" (sometimes misnamed "Hanning", > but that is an old misnomer). i have never heard of a "sine window" and i > have been doing this for 45 years. perhaps the classic Fred Harris paper > on windows has a "sine window". > > > ... actually sums to 1, > > that's what we mean by "complementary". > > > the proof of which can be found in audio coding theory. I suggest you > check out the book by Bosi. > > i didn't even know Marina did a book, but i am not surprized. i've known > (or been acquainted with) Marina since she was with Digidesign back in the > early 90s. before the Dolby Lab days. before her injury at the New York > Hilton in 1993. would you like me to introduce you to her at the next AES? > > Eric, you gotta get the basics down right and you gotta learn the correct > terminology if you're going to communicate with other people about this > topic matter. Neologisms are frowned on but people do them anyway. > However you just cannot change the meanings of terms that have existed > since the 1960s (and some as far back as the 1930s). > > -- > > r b-j r...@audioimagination.com > > "Imagination is more important than knowledge." > ___ 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
Well I believe the system is LTI just because the DFT is LTI by definition. The impulse response of a rectangular window I believe is that of a sinc function, which has ripple artifacts. Actually, the overlap-add method (sorry I don't have time to dig into the differences between overlap-add and overlap-save right now) minimizes artifacts depending on the windowing function. A sine window actually sums to 1, the proof of which can be found in audio coding theory. I suggest you check out the book by Bosi. Thanks, -ez On Sun, Mar 8, 2020, 3:01 PM robert bristow-johnson < r...@audioimagination.com> wrote: > > > > On March 8, 2020 2:00 PM Zhiguang Eric Zhang wrote: > > > > 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 > wrote: > > > the frequency response is a function of the windowing function > > > > > > > > what frequency response, Eric? if the only sample the "zero-phase system" > depends on is the present sample, not past nor future samples, then the > system is a wire or simply a scaler (if it's linear) or some other > memoryless function if it's nonlinear. we normally mean linear systems > when we discuss "frequency response". > > people here on this list are pretty competent about what linear system > theory is, what makes systems linear or not, what makes them time-invariant > or not, what makes for causal and acausal systems, what determines the > frequency response of a linear system (it's the impulse response), what > window functions are and their effect on the spectra of signals, what > linear-phase systems are and what hypothetical zero-phase systems are. > this is all in textbooks. > > one thing that needs to happen for anyone to truly assist anyone else > here, is that communication is unambiguous and accurate. that means we > really have to agree on the definitions of terms. > > an FIR filter is a linear, time-invariant system. it can be a > linear-phase system, but it doesn't have to be. that depends on the IR, > which is F. if and only if the IR is symmetrical, it's linear-phase. a > linear-phase FIR can be modeled as a hypothetical zero-phase FIR (so only > magnitude response is in its description) followed or preceded by a delay > of 1/2 of the length of the FIR. the phase response of a delay is a linear > function of frequency, hence "linear phase". a hypothetical zero-phase > filter is one with symmetry about the t=0 axis of the impulse response. > that means that samples in the future of the IR are a mirror image of > samples in the past. add some delay and you can move all of the non-zero > samples to the past (and one for the present input sample). > > using the FFT (and iFFT and frequency-domain multiplication of the > frequency response) is an operation we often call "fast convolution". fast > convolution is used for very long (but still finite) FIRs. for short FIRs > we just do it the simple way, a dot-product of the IR against the most > recent input samples. fast convolution is performed using one of two > techniques: "overlap-add" (OLA) and "overlap-scrap" (OLS). the older lit > will say "overlap-save" for OLS, but we mean the same thing. > > normally, the only windowing we do for fast convolution, is the > rectangular window. because of the overlapping and the linear-system > nature of the operation, there are no windowing effects. it *is* possible > to do something like fast convolution FIR with overlap-add using a > different window as long as it is complementary in the overlap (such as a > Hann window), but it makes the operation less "fast". if there is 50% > overlap, the number of net output samples computed in each frame is 1/2 > that for using rectangular given both windows having the same non-zero > length, so it would be half as efficient. > > lastly, this "overlap-add" method of fast convolution should not be > confused with the overlap-add method of the STFT processing music DSP > people often use for more general and sophisticated processing of audio > (such as a phase vocoder). generally more sophisticated than an FIR. in > that application, a rectangular window would be considered pretty bad. but > all this is not what "fast convolution" is, which we use to implement long > FIR filters (like reverberators). > > i'm just trying to be helpful, but none of us can really be helpful if we > cannot at least agree on the terminology. > > -- robert > > r b-j r...@audioimagination.com > > "Imagination is more important than knowledge." > > > > > 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 > 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
Re: [music-dsp] FIR blog post & interactive demo
> On March 8, 2020 2:00 PM Zhiguang Eric Zhang wrote: > > 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 wrote: > > the frequency response is a function of the windowing function > > > > what frequency response, Eric? if the only sample the "zero-phase system" depends on is the present sample, not past nor future samples, then the system is a wire or simply a scaler (if it's linear) or some other memoryless function if it's nonlinear. we normally mean linear systems when we discuss "frequency response". people here on this list are pretty competent about what linear system theory is, what makes systems linear or not, what makes them time-invariant or not, what makes for causal and acausal systems, what determines the frequency response of a linear system (it's the impulse response), what window functions are and their effect on the spectra of signals, what linear-phase systems are and what hypothetical zero-phase systems are. this is all in textbooks. one thing that needs to happen for anyone to truly assist anyone else here, is that communication is unambiguous and accurate. that means we really have to agree on the definitions of terms. an FIR filter is a linear, time-invariant system. it can be a linear-phase system, but it doesn't have to be. that depends on the IR, which is F. if and only if the IR is symmetrical, it's linear-phase. a linear-phase FIR can be modeled as a hypothetical zero-phase FIR (so only magnitude response is in its description) followed or preceded by a delay of 1/2 of the length of the FIR. the phase response of a delay is a linear function of frequency, hence "linear phase". a hypothetical zero-phase filter is one with symmetry about the t=0 axis of the impulse response. that means that samples in the future of the IR are a mirror image of samples in the past. add some delay and you can move all of the non-zero samples to the past (and one for the present input sample). using the FFT (and iFFT and frequency-domain multiplication of the frequency response) is an operation we often call "fast convolution". fast convolution is used for very long (but still finite) FIRs. for short FIRs we just do it the simple way, a dot-product of the IR against the most recent input samples. fast convolution is performed using one of two techniques: "overlap-add" (OLA) and "overlap-scrap" (OLS). the older lit will say "overlap-save" for OLS, but we mean the same thing. normally, the only windowing we do for fast convolution, is the rectangular window. because of the overlapping and the linear-system nature of the operation, there are no windowing effects. it *is* possible to do something like fast convolution FIR with overlap-add using a different window as long as it is complementary in the overlap (such as a Hann window), but it makes the operation less "fast". if there is 50% overlap, the number of net output samples computed in each frame is 1/2 that for using rectangular given both windows having the same non-zero length, so it would be half as efficient. lastly, this "overlap-add" method of fast convolution should not be confused with the overlap-add method of the STFT processing music DSP people often use for more general and sophisticated processing of audio (such as a phase vocoder). generally more sophisticated than an FIR. in that application, a rectangular window would be considered pretty bad. but all this is not what "fast convolution" is, which we use to implement long FIR filters (like reverberators). i'm just trying to be helpful, but none of us can really be helpful if we cannot at least agree on the terminology. -- robert r b-j r...@audioimagination.com "Imagination is more important than knowledge." > > On Sun, Mar 8, 2020 at 10:34 AM robert bristow-johnson > > wrote: > > > > > > > > > > On March 8, 2020 10:05 AM Ethan Duni 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 > > > 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
Re: [music-dsp] FIR blog post & interactive demo
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 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 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 >> 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 >> 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
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 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 > 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 > 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=saJ0IC40JGWeOGaONJ6jTXPSJtWmpzejoo8nX3eSWs8=WXWL91lRoTbvxjpEmSd4HWZBuRlfWGw7fwG4xVWHIvI= ___ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu
Re: [music-dsp] FIR blog post & interactive demo
> On March 8, 2020 10:05 AM Ethan Duni 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 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 https://lists.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] FIR blog post & interactive demo
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 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 >> 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 ___ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
