[Speex-dev] question about spx_fft

[Jean-Marc Valin]

(keeping this on the list)

William Zhang wrote:
> I read the mdf.c an my understanding is that N is actually window size for
> the FFT. The actual length L = N/2 which is the frame length.  The
> second part of the buffer is padded with the new frame data.  So this is
> like the overlap-save method for improving the acuracy in calculating
> the fft of
> long sequence of data?

The reason for the zero padding is that it's the only way to compute the
convolution correctly in the frequency domain (that is, without circular
convolution effects).

> My hardware logic can perform N real point FFT real fast and it produce
> N complex fft results

If that's the case, then you can still benefit by converting the N-point
real FFT into an N/2 point complex FFT and an update pass.

> RIRIRI...RI. How does it map to your N/2 complex
> output especially
> the first R and last R in your sequecne? 

The packing is actually R(0), R(1), I(1), R(2), I(2), ... R(N/2)

Because the input is real, it means that I(0) and R(N/2) are equal to
zero (so we don't need to include them). Also, everything above N/2 is
the complex conjugate of what's below so it's uninteresting as well.


> And do you think the hardware
> approach will fit in
> your AEC module?

Sure, use the right ordering (and be careful with scaling!) and it'll work.

	Jean-Marc