Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:4469] fft stuff

Date2004-04-10 10:27
From"Matt J. Ingalls"
Subject[CSOUND-DEV:4469] fft stuff
whats the difference between fft.c, dnfft.c, and mxfft.c?
any difference in speed?

ive been looking into implementing real-time low latency convolution
[pvsconvolve?] for large IRs and
found some music-dsp discussion from 2001 that Richard Dobson was
considering doing it.  Did you ever do any work on that Richard?

-m





Date2004-04-10 10:58
FromRichard Dobson
Subject[CSOUND-DEV:4470] Re: fft stuff
On convolution, yes (but Csound acquired "convolve", which is as much as I would 
have  been able to do), but not on low-latency convolution. This is a sensitive 
subject, as Anders Torger got all sorts of grief from Lake DSP when he produced 
a low-latency convolution open-source package called "Brute-FIR", which 
implements standard equal-block partitioned fast convolution.  Unfortunately 
(for me), his code is heavily unix-oriented, with fork calls all over the place 
(something I barely understand at all!), and I have not yet tried to implement 
the algorithm in a "simpler" way. I beleive Angelo Farina is working on 
something similar, and hopefully in a form compatible with Csound and the LGPL.


mxfft.c is the conversion of the orginal CARL fft code in FORTRAN, converted to 
C by CDP years ago (Trevor Wiwhart et al), hence all the spaghetti-like goto 
code. It is nowhere near as fast as something like FFTW, but pretty fast for a 
single-file C implementation. I feel that it is faster than the older Csound 
implementation, but have done no benchmarks, and the difference in in any case 
not great.  mxfft.c supports any even-numbered fft size (as does FFTW), which 
can be very useful. The other versions are (AFAIK) limited to the usual 
power-of-two sizes.

Richard Dobson


Matt J. Ingalls wrote:

> whats the difference between fft.c, dnfft.c, and mxfft.c?
> any difference in speed?
> 
> ive been looking into implementing real-time low latency convolution
> [pvsconvolve?] for large IRs and
> found some music-dsp discussion from 2001 that Richard Dobson was
> considering doing it.  Did you ever do any work on that Richard?
> 
> -m
> 
> 
> 

Date2004-04-10 19:46
From"Matt J. Ingalls"
Subject[CSOUND-DEV:4473] Re: fft stuff
> On convolution, yes (but Csound acquired "convolve", which is as much as I would
> have  been able to do), but not on low-latency convolution. This is a sensitive
> subject, as Anders Torger got all sorts of grief from Lake DSP when he produced
> a low-latency convolution open-source package called "Brute-FIR", which
> implements standard equal-block partitioned fast convolution.  Unfortunately
> (for me), his code is heavily unix-oriented, with fork calls all over the place
> (something I barely understand at all!), and I have not yet tried to implement
> the algorithm in a "simpler" way. I beleive Angelo Farina is working on
> something similar, and hopefully in a form compatible with Csound and the LGPL.

i was indeed thinking of trying to implement farina's approach from one of
his papers and have looked at brutefir's web site and was about to look at
his code.  first thought i could do it in csound code itself but will
probably be easier as an opcode.

>
>
> mxfft.c is the conversion of the orginal CARL fft code in FORTRAN, converted to
> C by CDP years ago (Trevor Wiwhart et al), hence all the spaghetti-like goto
> code. It is nowhere near as fast as something like FFTW, but pretty fast for a
> single-file C implementation. I feel that it is faster than the older Csound
> implementation, but have done no benchmarks, and the difference in in any case
> not great.  mxfft.c supports any even-numbered fft size (as does FFTW), which
> can be very useful. The other versions are (AFAIK) limited to the usual
> power-of-two sizes.

yes i have to say i was a bit shocked looking at the code for mxfft!

the dnfft.c seemse the cleanest and easiest to use..

-m

>
> Richard Dobson
>
>
> Matt J. Ingalls wrote:
>
> > whats the difference between fft.c, dnfft.c, and mxfft.c?
> > any difference in speed?
> >
> > ive been looking into implementing real-time low latency convolution
> > [pvsconvolve?] for large IRs and
> > found some music-dsp discussion from 2001 that Richard Dobson was
> > considering doing it.  Did you ever do any work on that Richard?
> >
> > -m
> >
> >
> >
>
>