Thanks Takehiro.
(1) Could you also please provide an overview of and clarify the parameters
to fft_long() ?
void fft_long(lame_internal_flags * const gfc,
FLOAT x[BLKSIZE], int chn, const sample_t *buffer[2] )
- gfc is used to obtain a pointer to the blackman window, of size ???
- x contains the data to be transformed, in sequential order ???
- chn = ???
- buffer = ??? sample data, left/right channel???
(2) Apple's vDSP library features an In-Place Real Fourier Transform.
Hence, I'm trying to isolate the code in fft.c which does the same thing.
That is, a fft that operates on time-domain data in time series.
I don't understand (yet) the LAME functions / interfaces and it seems there
are quite a few optimisation hacks which will make isolating the code
harder. Thus, any tips much appreciated...
Cheers
Simon
On Saturday, September 7, 2002, at 06:49 PM, Takehiro Tominaga wrote:
Hi, ruffnex.
I am looking forward to AltiVec optimized LAME :)
r == ruffnex [EMAIL PROTECTED] writes:
r After gprof'ing Lame 3.92, and looking at the source, I think
r fht.c might be an ideal candidate for vectorising with OSX's
r Altivec optimised DSP library.
Yes, the code is easy to optimize with the SIMD instructions
but currently, only 3DNow!-ed code is available which I ported from GOGO.
r (1) Function arguments
r static void fht(FLOAT *fz, int n)
r *fz = ptr to time-domain data (in what order ?)
the order is 'bit-reversed series order'.
See the fft_short() and fft_long() functions in fft.c for the details.
r n = the size of the input data to transform e.g. n-point dft
r (what is the valid range for n ?)
only 256 or 1024.
r (2) the function is in-place (that is, the input data is
r over-written by the output data)
yes, you are right. the calculation is done by in-place algorithm.
--
Takehiro TOMINAGA // may the source be with you!
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
