when should one perform fft based filtering?
in [DSP]
|
From: robert bristow-johnson on 25 Jul 2010 12:49 On Jul 24, 4:01 pm, Jerry Avins <j...(a)ieee.org> wrote: > On 7/24/2010 3:10 PM, Nasser M. Abbasi wrote: > > > > > On 7/24/2010 11:08 AM, Steve Pope wrote: > > >> I so often here a question of the form, "How do I use an FFT > >> to do X", without the questioner having considered that > >> they can solve their problem in the time domain. > > > The teacher keep telling our class that the most common operation in > > digital world is convolution, and fft is a fast way to do this. So why > > would any one do convolution in time domain? isn't that much slower? so, > > for convolution, first choice is fft, right? > > > I am just talking about convolution here. btw, the overlap save > > procedure (and there was another one like it?) was hard to understand > > for me, but luckly we did not get that in the exam, else I might have > > failed. > > You didn't read the other branch of the thread and follow rbj's link. > Small convolutions are faster directly in the time domain. Defining > "small" is the topic of this thread. > thanks for noticing, Jerry. sometimes i think i'm talking to a wall. but since you're not a wall, that delusion is disproved. r b-j
From: Rune Allnor on 25 Jul 2010 13:03 On 25 Jul, 18:43, robert bristow-johnson <r...(a)audioimagination.com> wrote: > On Jul 25, 8:39 am, Rune Allnor <all...(a)tele.ntnu.no> wrote: > ... > > > Sure, embedded devices might be able to do stuff like FFTs > > very efficiently, but they would struggle with the control > > loops necessary to fuse subsequent frames. > > bookkeeping. > > > Again, the only relevance I can see for overlap-add/save these > > days, is to reduce numerical noise in large *offline* work. > > how about a real-time convolution reverberator based on an measured > impulse response of an actual large room (like a venerated auditorium > or cathedral)? FIR with a couple hundred thousand taps? What about it? Rune
From: Jerry Avins on 25 Jul 2010 22:09 On 7/24/2010 9:16 PM, Randy Yates wrote: >> Rune Allnor<allnor(a)tele.ntnu.no> writes: ... >> Before you ask - the overlap-save and overlap-add methods are >> compromises > > How so? Because the stride through the data is a fraction of the FFT size, some of the efficiency of fast convolution is lost and the crossover size increases. ... Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
From: robert bristow-johnson on 25 Jul 2010 23:27 On Jul 25, 1:03 pm, Rune Allnor <all...(a)tele.ntnu.no> wrote: > On 25 Jul, 18:43, robert bristow-johnson <r...(a)audioimagination.com> > wrote: > > > On Jul 25, 8:39 am, Rune Allnor <all...(a)tele.ntnu.no> wrote: > > ... > > > > Sure, embedded devices might be able to do stuff like FFTs > > > very efficiently, but they would struggle with the control > > > loops necessary to fuse subsequent frames. > > > bookkeeping. > > > > Again, the only relevance I can see for overlap-add/save these > > > days, is to reduce numerical noise in large *offline* work. > > > how about a real-time convolution reverberator based on an measured > > impulse response of an actual large room (like a venerated auditorium > > or cathedral)? FIR with a couple hundred thousand taps? > > What about it? well, it would be a helluva convolution machine to do it solely in the time-domain. being that a reverberator is an audio device, its sampling rate would need to be about 44.1 kHz or higher. for a monophonic reverb (what good is that?), 44100 samples/second x 200000 multiplies/sample is about 9 giga-OPs. how many might it be if this were done with fast convolution? probably, since a 256K or 512K or 1 Meg FFT might be numerically difficult, you would have to divide the impulse response into segments and fast-convolve each segment with a smaller FFT. from the POV of an audio person, that was the main reason for learning about overlap-add or overlap-save in the first place. r b-j
From: steveu on 26 Jul 2010 02:04
>> Rune Allnor <all...(a)tele.ntnu.no> writes: >I don't really see why one would want to do offline work on >embedded devices. Many instruments do a fast grab of data, and then analyse it in a fairly leisurely way in some kind of embedded processor. Steve |