# ezFFT latency

Member Posts: 7 Member

Hi all! I am looking for a solution to some ezFFT limitations that I would really like to expand. I am talking about latency. For a window size of 128 bins and a sampling frequency of 32000, the latency is 20 ms. Is there a way to reduce the latency while maintaining the frequency step width? Maybe there is a way to double the algorithm by splitting it into two calculation threads? Or double the sampling frequency, but only calculate up to 16kHz? Thanks!

• Member Posts: 17 Member

Hi,

There's a fundamental limit that can't be beaten: one block length. On an ideal, infinitely fast computer, this would be the (pure FFT) latency due to block-wise calculations. For 128 bins, this equals 256 samples. At 32k, this results in 8 ms. The already optimized EzFFT build for streaming audio needs 20 ms (5/2 of 8 ms) because it waits for a complete block, performs calculations, and then transmits via the audio stream.

Using a higher sample rate doesn't solve this problem; you still need a block size that covers roughly one bass frequency cycle.

https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/10267/

took a while to build but significantly reduced latency by using event iterations instead of the audio stream. You can switch overlap and block size, but it makes the system a bit unreliable, resource-intensive, and more complicated to develop with.

Cheers,

Jan

• Member Posts: 17 Member

Hi,

There's a fundamental limit that can't be beaten: one block length. On an ideal, infinitely fast computer, this would be the (pure FFT) latency due to block-wise calculations. For 128 bins, this equals 256 samples. At 32k, this results in 8 ms. The already optimized EzFFT build for streaming audio needs 20 ms (5/2 of 8 ms) because it waits for a complete block, performs calculations, and then transmits via the audio stream.

Using a higher sample rate doesn't solve this problem; you still need a block size that covers roughly one bass frequency cycle.

https://www.native-instruments.com/de/reaktor-community/reaktor-user-library/entry/show/10267/

took a while to build but significantly reduced latency by using event iterations instead of the audio stream. You can switch overlap and block size, but it makes the system a bit unreliable, resource-intensive, and more complicated to develop with.

Cheers,

Jan

Reaktor doesn't report latency to your daw but there's a track marker in the user library. If I remember it produces a click at the start of a recording. It makes it fairly easy to get an idea of the latency your fft ensemble has. https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/14137/

• Member Posts: 7 Member

Thanks for the answer, but what you answered has nothing to do with my question. It's about the ezFFT module from the user library. And by the way, the first answer was exhaustive.