Multiple different length Windows for high resolution realtime FFT

Question

I am looking at trying to achieve a 'realtime' (as quick as possible to acquire, process and present data) FFT application to analyse audio.

I have setup my app to acquire a set of samples, apply a 50% overlap window function, zero pad, compute FFT, extract magnitude and phase and display these. Currently I can do this with no issues, and minimal latency to the incoming signal.

However, as I have chosen a small sampling window (2048 samples) to achieve a fast time, I realise that this hinders resolution. I am also aware that there is only so much zero padding can achieve, if the acquired data is not there to begin with.

So my question is to do with how to achieve a better resolution for lower frequencies. It is my understanding that for accuracy, the time window should contain at least one cycle of the lowest frequency.

Is there a way that I can perform multiple FFTs on a signal with varying lengths and 'glue' the resultant FFT together. ie, a longer FFT will do the lower frequency range, and a shorter for the higher range. And if I can do this, will this retain phase information, or will I lose this completely?

Answer 1

You can, and you don't need to zero pad, but a little overlapping does come into play.

Skipping the gnarly details and hitting this with a conceptual approach. Applies to two or more "levels".

Start with a longer frame for your low tones. The key is you need to smooth your signal fairly heavily. Lots of ways to do this. Then do a DFT (what a FFT really is) on the long interval. The reason for the smoothing is to eliminate alias frequencies at this level. The effects of your smoothing will be frequency dependent, so there are formulas for the different smoothing techniques. Do the inverse of the FFT of the smoothed signal with attenuation compensation applied. Subtract this from your original signal. You have now documented and removed your lower frequencies. Divide the interval into smaller chunks, and do DFTs as normal at the top level.

"Pasting" them together can also be done in different ways. Easiest is just to display one spectogram above the other as "display bands". You can also rescale the output from being linear in frequency to exponential if you want to put your results on an octave scale.

Answer 2

For a stationary spectral peak well above the noise floor and interference, look up phase vocoder frequency estimation techniques.

If a clear peak (maxima) appears in the same result bin in multiple overlapped FFT window, by using the change in phase in that FFT bin across successive offset windows (of known offset or overlap), a frequency estimate of higher resolution than the FFT bin spacing can often be acquired (again, depending on the S/N ratio).

Using the information from multiple overlapped windows is what allows the information gain to provide an improved frequency estimate, similar to the information gain of using a longer FFT. But you still get some trailing time resolution (if a frequency peak disappears from the last window). And if you run a phase vocoder backwards in time, you might also get some (non-real-time obviously) leading edge time resolution.

One problem with FFTs shorter than a few periods of the lowest frequency desired is that, near DC (or Fs/2), the side lobes from the conjugate mirror image (of any strictly real signal) is nearby, thus can leak in and distort phase estimation accuracy.

Answer 3

The basis functions of the DFT can be viewed as (complex) filter kernels. You could have a bank of N complex FIR filters of N taps producing an output every sample (similar to a maximally overlapping FFT filterbank). You would probably apply some window function.

Those filters would produce «sharp» template matching for the full length N inner product. But perhaps a subset of the inner product (before all samples have arrived) could give some blurry preliminary info (sort of like how progressive gif/jpeg gave a blurry preview before our measly modem had time to download the entire file).

I assume that you would have better results if you designed «short latency» and «long ltency» filters separately, rather than trying to reuse one in the other. The window function would typically be messed up.