<span style="color: rgb(51, 102, 255);">Thanks for the explaination. Please see my questions and comment in lines. </span><br><br>On 4/16/07, Jean-Marc Valin <<a href="mailto:jean-marc.valin@usherbrooke.ca">jean-marc.valin@usherbrooke.ca
</a>> wrote:<br>> (keeping this on the list)<br>> <br>> William Zhang wrote:<br>> > I read the mdf.c an my understanding is that N is actually window size for<br>> > the FFT. The actual length L = N/2 which is the frame length. The
<br>> > second part of the buffer is padded with the new frame data. So this is<br>> > like the overlap-save method for improving the acuracy in calculating<br>> > the fft of<br>> > long sequence of data?
<br>> <br>> The reason for the zero padding is that it's the only way to compute the<br>> convolution correctly in the frequency domain (that is, without circular<br>> convolution effects).<br>> <br>> > My hardware logic can perform N real point FFT real fast and it produce
<br>> > N complex fft results<br>> <br>> If that's the case, then you can still benefit by converting the N-point<br>> real FFT into an N/2 point complex FFT and an update pass.<br><span style="color: rgb(51, 102, 255);">
This is what the kiss_fftr function does, right? <br><br></span>> > RIRIRI...RI. How does it map to your N/2 complex<br>> > output especially<br>> > the first R and last R in your sequecne?<br>> <br>> The packing is actually R(0), R(1), I(1), R(2), I(2), ... R(N/2)
<br><br>> Because the input is real, it means that I(0) and <span style="color: rgb(204, 0, 0);">R(N/2)</span> are equal to<br> <span style="color: rgb(51, 51, 255);">
I think you mean I(R/2), correct?</span><br>> zero (so we don't need to include them). Also, everything above N/2 is<br>> the complex conjugate of what's below so it's uninteresting as well.<br>> <br>
> <br>> > And do you think the hardware<br>> > approach will fit in<br>> > your AEC module?<br>> <br>> Sure, use the right ordering (and be careful with scaling!) and it'll work.<br><br><span style="color: rgb(51, 51, 255);">
In the FIX_POINT version of the spx_fft function, where is the actual code that do</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">the forward FFT normaliaztion by 1/N? I saw the code first maxmize the input
</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">before the FFT and renormalize it back afterwards. Isn't this making the signal bigger</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">
and easy to overflow? If I am not mistaking, the input to the kiss_fft is the 2's complement<br>value. <br style="color: rgb(51, 51, 255);"></span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">
I use the Xilinx Logicore FFT IP which also supports the 16bit fixed point FFT and it</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">has some internal scaling for each stage. Do I need to match the same scaling of 1/N
</span><br style="color: rgb(51, 51, 255);"><span style="color: rgb(51, 51, 255);">in the software code? </span><br style="color: rgb(51, 51, 255);"><br>> Jean-Marc<br>> <br>> <br>