On 11/26/2009 11:58 PM, [email protected] wrote: >> I've tried hard to understand where the problem was, and one thing I'm sure >> about is that you fft'ize a given block of input twice, once with the >> ascending >> part of the window applied (in R1), then again the same block of data >> multiplied >> with the descending part of the window (in R2). > > That's correct. But the first time you combine the first half > of the current block with the second half of the previous, > and the second time you combine the second half of the current > block with the first half of the *next*. I think you failed to > do that somehow.
I need to read some good book about all of this when I found some time. You know my profile a bit now I think, I'm basically a long time coder with little math/signal processing background. What book would you recommend? >> Anyway you method did solve my problem, and I now still have a lot of work, >> because I need all of this to run with integers (fixed point fft) and the >> joys >> of overflow.. > > Integer FFTs can be lots of fun :-) I sense that ;) Actually, this code is intended to run on an increasingly popular Linux distribution: Android. Which currently means arm and no fpu (gcc -msoft-float). However, floats are so handy that I'm first going to check how much cpu time the current code consumes. > One trick you may try (if you write the FFT yourself) is to > distribute the 'scale' thing over the internal iterations of > the FFT. Either shift by one bit each iteration in the FFT, > or in the IFFT, or do it each *second* iteration in both. > Which is best depends on the application, and the type of > signal which you process. No I want to use kissfft. I don't have the skills nor the time to implement the fft myself, although I would quite like to have some sort of control on that bloody scale thing. Doing an fft+ifft with kissfft basically scales down the frames by fftsize. So if fftsize is 1024, all samples are scaled down by 10 bits, which got me crazy when I first tried with int16 (Q15). > Another thing: you are aware that this method is not just > a filter ? It also modulates the signal... How bad it gets > depends on the frequency response you try to obtain. My usual frequency response measure instrument (hear ;) is saying that with the current code, the output is very similar to the input. So that should be ok. That said, do you have any recommendation about the fftsize? Basically, what I want to do is something like spectral noise gating, similar to what's implemented in Audacity: http://wiki.audacityteam.org/index.php?title=Noise_Removal I'm however also interested in so-called spectral subtraction. I tend to think that although it may be simpler, it won't give such good results as the gating, which are quite amazing to me, when applied to speech. -- Olivier _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
