[CSOUND-DEV:4469] fft stuff
Date | 2004-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 |
Date | 2004-04-10 10:58 |
From | Richard 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 > > > |
Date | 2004-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 > > > > > > > > |