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

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

Hello Shafik,

> voice1 -> ADC -> DSP -> DAC -> voice2

First: This MUST work.

> 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.

Sample size does not matter at a first glance.
Be aware that handled values become greater the longer your sample size is.
With 16-bit fixed point you might run into trouble with number sizes.

> The FFT routines are verified to be "correct". 

How have you proved that ? Make a very simple test:
What's your ADC's Bit-Resolution ? Make a waveform of 
MAX-Value -MAX-Value as a square wave.
->FFT->IFFT should give you a result with "noise" !
(Because something is wrong with FFT-routine)
If not there might be a problem with the representation of numbers which you give
to the DAC.

> 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.

Window has nothing to do with your problem.
If you use no Window ("Boxcar") you should get out what you did in.
(Frame size can touch your number area. See above)

> Any insight would be largerly appreciated.

                                Hope these hints were a starting point,

                                                                        Wolfgang

Shafik,

are you sure you do overlap-add (or overlap-save) in your 
implementation? If you're unsure how to do this, there's code for pitch 
shifting using the STFT on my web site (s.b.) that you can use to do 
plain STFT processing, too.
-- 
Stephan M. Bernsee
http://www.dspdimension.com

Of course this should work, as IFFT(FFT(x))=x... So you do have a bug
somewhere. My guess : are you sure that you don't have any overflows in the
FFT calculations ? As a starting point try to limit your input values to 8
or 10 bits (ie +/-1024 only but coded on 16 bits numbers), if it is not
already the case.

Good luck,
Friendly yours,

-- 
Robert Lacoste
ALCIOM - The mixed signal experts
www.alciom.com


"Shafik" <shafik@u.arizona.edu> a &#4294967295;crit dans le message de
news:cibhl1$klg@odak26.prod.google.com...
> 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
>

Shafik,

Does your FFT produce output in bit-reversed or natural order? Does the IFFT
take its input in bit-reversed or natural order? What about the output of
the IFFT?

Regards,
-- Georgi


"Shafik" <shafik@u.arizona.edu> wrote in message
news:cibhl1$klg@odak26.prod.google.com...
> 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
>

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.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On 2004-09-16 19:48:10 +0200, Jerry Avins <jya@ieee.org> said:

> 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.
> 
> Jerry

Well, if he's just chopping up the signal and does a transform and an 
inverse he should still get back what he started with (more or less) if 
he doesn't change anything, but that certainly isn't practical.
-- 
Stephan M. Bernsee
http://www.dspdimension.com

"Jerry Avins" <jya@ieee.org> a &#4294967295;crit dans le message de
news:4149d1db$0$2678$61fed72c@news.rcn.com...
> 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.

I think you're wrong : If you take any data array, then calculate its FFT
and then IFFT (as complex figures of course and without any
truncation/rounding errors), then your output array is exactly identical to
the input, even if the input array is random. So if you digitize an input
signal in blocks, say of 256 samples (without any "gaps" of course), do the
FFT/IFFT on each block, then output the result at the same rate, then you
should find back exactly the same signal.

Can someone confirm ?

Cheers,
Robert

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.
> 
> Jerry

Nope. For a finite block of discrete-time data x, IFFT(FFT(x))==x to 
within numerical precision. The periodic extension argument comes in 
when one tries to interpret the results of finite-time Fourier integrals 
of continuous functions.

Try an make a file with voice data (or broad-band data), run it through
the FFT-IFFT program and store the result to file. It should match the 
original file to within numerical precision. If this works, your problem 
is with the ADC/DAC. If it doesn't work, you have a problem in the DSP SW.

If the FFT/IFFT of the sine signal works to within numerical precision, 
I'd look for snags in the sampling. From the flow chart in the first 
post, it seems as if the ADC and DAC are parts of the signal flow here. 
Is there a decent anti-aliasing filter in the flow? That's where I would 
start.

Rune

Well heres something interesting. I changed the frame size to 64
instead of 256, and the noise was significantly reduced. I still high a
weird throbbing whine at the frequency of the frame switching.

At any rate, I wouldnt expect that a smaller size frame would get
better quality. Maybe the DSP package that Im using isnt as good as I
thought it was.

BTW Im using Motorolas 56F8323 EVM board. Their SDK is version 6.0, so
I would hope that basic FFT and IFFT routines functional properly.
What now? :-)
--Shafik