DSPRelated.com
Forums

Real time FFT voice processing...why wont it work?

Started by Shafik September 16, 2004
There is a paper from the early 1970s which talks about the errors in fixed 
point FFTs.  If I remember correctly, the errors increase as the square root 
of the of either the FFT size of the power of two that is the FFT size.  That 
would apply in both directions.  It would also explain why the noise decreases 
when the FFT size is reduced.

In article <cibhl1$klg@odak26.prod.google.com>, "Shafik" 
<shafik@u.arizona.edu> wrote:
>Hello all, > >I am curious why such a system does NOT work. I am using a 16-bit >fixed-point DSP chip: > >voice1 -> ADC -> DSP -> DAC -> voice2 > >I collect an array of samples and pass them through an FFT then an >inverse FFT. The sample size is 256 but obviously, that can be changed. > >The FFT routines are verified to be "correct". Yet, when doing and FFT >-> IFFT, the voice coming out is very noisy, and only slightly >resembles the incoming voice. Why is this? >Note that when I pass the signal straight through with not FFT, its >perfectly clear. In other words, Im sure the problem is not due to >aliasing/undersampling/etc. > >Im wondering if I need to window the sample data each "frame" or if I >need to get a new chip that would support much bigger >frame size, such as 2048 or 4096. >Any insight would be largerly appreciated. > >Thanks, >--Shafik >
Jerry Avins <jya@ieee.org> wrote in message news:<4149d1db$0$2678$61fed72c@news.rcn.com>...
> Robert Lacoste wrote: > > > Of course this should work, as IFFT(FFT(x))=x ... > > That's true only if all the data are dealt with at once, and if they > represent one cycle of something that repeats. For non-repetitive > inputs, one must use an overlap method.
Hold the phone, there, Jerry. If the fellow does NO, and I mean NO processing, then in fact he should get out exactly what he puts in. There is no need to have "one cycle of something that repeats", x=ifft(fft(x)) in all cases with finite energy, unless of course you overload, have calculation problems, or something like that. Now, if he wants to process what he's doing by anything more than a fixed gain, pretty much, then he needs to window and overlap add, or the periodicity of the basis vectors is going to pound him to bits. More specifically, if he puts in 'n' samples to an 'm' length fft, the fft at m length of whatever modification he does had better not have a length of more than m-n+1. This is why MDCT's, OBT, LOT's and the like are so handy to have. Of course, each non-oversampled kind of filterbank or transform has its own warts. For any valid data input x, x=ifft(fft(x)=fft(ifft(x)) also = conj(fft(conj(fft(x)))) if I remember correctly, at least. 'Tain't just a good idea, neither, it's the law, so to speak. mark
"Mark Ovchain" schrieb 
> > > > > Of course this should work, as IFFT(FFT(x))=x ... > > > > That's true only if all the data are dealt with at once, > > and if they represent one cycle of something that repeats. > > For non-repetitive inputs, one must use an overlap method. > > Hold the phone, there, Jerry. > > If the fellow does NO, and I mean NO processing, then in fact > he should get out exactly what he puts in. >
One question: The OP samples n points, then does the FFT, then some transformation, then an IFFT, then output. If he does this in a single thread, then some distortion would have to be heard, since during the IFFT(transform(FFT(input))) phase no data is being acquired, no? I think, a data acquisition thread should fill an input buffer, a computing thread should do IFFT(transform(FFT(input)))into an output buffer and an output thread should do the output. Regards Martin
Mark Ovchain wrote:

> Jerry Avins <jya@ieee.org> wrote in message news:<4149d1db$0$2678$61fed72c@news.rcn.com>... > >>Robert Lacoste wrote: >> >> >>>Of course this should work, as IFFT(FFT(x))=x ... >> >>That's true only if all the data are dealt with at once, and if they >>represent one cycle of something that repeats. For non-repetitive >>inputs, one must use an overlap method. > > > > Hold the phone, there, Jerry. > > If the fellow does NO, and I mean NO processing, then in fact he > should get out exactly what he puts in. > > There is no need to have "one cycle of something that repeats", > x=ifft(fft(x)) in all cases with finite energy, unless of course you > overload, have calculation problems, or something like that. > > Now, if he wants to process what he's doing by anything more than a > fixed gain, pretty much, then he needs to window and overlap add, or > the periodicity of the basis vectors is going to pound him to bits. > More specifically, if he puts in 'n' samples to an 'm' length fft, the > fft at m length of whatever modification he does had better not have a > length of more than m-n+1. > > This is why MDCT's, OBT, LOT's and the like are so handy to have. Of > course, each non-oversampled kind of filterbank or transform has its > own warts. > > For any valid data input x, x=ifft(fft(x)=fft(ifft(x)) also = > conj(fft(conj(fft(x)))) if I remember correctly, at least. > > 'Tain't just a good idea, neither, it's the law, so to speak. > > mark
You and others are right; I was wrong. I assumed processing, not the test case Shafik was properly conducting before starting in earnest. He would do well to realize, though, that it's an incomplete test. Even if its output emerged undistorted, overlap methods are needed to permit the processing I think he wants to do. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
So far nothing has worked. I do realize if I manipulate the FFT data in
the frequency domain then I would get aliasing in the time domain after
the IFFT. Still, I want a simple frame to be FFTed then IFFTed with no
problem at all, since everyone here at least agrees that IFFT(FFT(x))
== x and Im unable to get that with the Motorola product.

The best Ive gotten was with the 64 size FFT. Am I just barking up the
wrong tree with using fixed-point FFT for voice processing? Should I be
using a true floating-point processor?

--Shafik

On Sat, 18 Sep 2004 03:59:51 GMT, george.w.bush@whitehouse.com (George
Bush) wrote:

>There is a paper from the early 1970s which talks about the errors in fixed >point FFTs. If I remember correctly, the errors increase as the square root >of the of either the FFT size of the power of two that is the FFT size. That >would apply in both directions. It would also explain why the noise decreases >when the FFT size is reduced. >
Hi, At the COMP.DSP Conference in Minnesota, last July, I overheard one of the attendees say something like: "I've found that using a 16-bit fixed point number format only provides acceptable FFT results if the FFT size is no greater than 2048." I don't know what the word "acceptable" meant, but I just remember the notion that with 16-bit words, the size of an FFT is limited if you expect useable (accurate-enough) results. [-Rick-]
Something I failed to menttion before, errors in the computation of the 
FFT/IFFT will show up as tones and noise in the output.  If you can, use 
floating point FFT.  Is this fixed point FFT fixed scales or block scaled?  In 
fixed scale, there is a divide by two every other pass to ensure that there is 
no overflow.  In block scaled, there is a divide by two as required to ensure 
there is no overflow.  Needless to say, the block scaled is more accurate.

In article <1095587215.974772.271280@h37g2000oda.googlegroups.com>, "Shafik" 
<shafik@u.arizona.edu> wrote:
>So far nothing has worked. I do realize if I manipulate the FFT data in >the frequency domain then I would get aliasing in the time domain after >the IFFT. Still, I want a simple frame to be FFTed then IFFTed with no >problem at all, since everyone here at least agrees that IFFT(FFT(x)) >== x and Im unable to get that with the Motorola product. > >The best Ive gotten was with the 64 size FFT. Am I just barking up the >wrong tree with using fixed-point FFT for voice processing? Should I be >using a true floating-point processor? > >--Shafik >
Shafik,

If you can change the FFT size by simply changing parameters in the
code, then read my post to your question on 09/16.

Dirk Bell


"Shafik" <shafik@u.arizona.edu> wrote in message news:<1095587215.974772.271280@h37g2000oda.googlegroups.com>...
> So far nothing has worked. I do realize if I manipulate the FFT data in > the frequency domain then I would get aliasing in the time domain after > the IFFT. Still, I want a simple frame to be FFTed then IFFTed with no > problem at all, since everyone here at least agrees that IFFT(FFT(x)) > == x and Im unable to get that with the Motorola product. > > The best Ive gotten was with the 64 size FFT. Am I just barking up the > wrong tree with using fixed-point FFT for voice processing? Should I be > using a true floating-point processor? > > --Shafik
Dirk,

The smallest size I can do is an 8 point FFT. I put in the sequence (0,
1, 0, -1, 0, 1, 0 -1) and got out an almost exact sequence:

(0, 0.99987, 0, -0.99987, 0, etc...)
What does that tell you?

--Shafik

Shafik,

Break it down into more steps, so we have more to look at.

Put the same sequence (0, 1, 0, -1, 0, 1, 0 -1)into the real part of
the fft input.
Verify that the imaginary parts of the fft input are zero.
Tell us what the real and imaginary parts of the fft output are.
Put the fft outputs (real and imaginary) into the ifft input.
Tell us what the real and imaginary parts of the ifft output are.

Repeat these steps with the sequence obtained by shifting the previous
input by 1 sample, ie use
{1, 0, -1, 0, 1, 0, -1, 0)

If any imaginary parts are zero, show that.

Dirk Bell


"Shafik" <shafik@u.arizona.edu> wrote in message news:<1095701778.647486.247330@k26g2000oda.googlegroups.com>...
> Dirk, > > The smallest size I can do is an 8 point FFT. I put in the sequence (0, > 1, 0, -1, 0, 1, 0 -1) and got out an almost exact sequence: > > (0, 0.99987, 0, -0.99987, 0, etc...) > What does that tell you? > > --Shafik