From: robert bristow-johnson on
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
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
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
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
>> 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