Benchmark against other libraries

[indutny]

This library is most likely one of the fastest implementations of Cooley-Tukey FFT algorithm. It would be interesting to see how it compares to other JS implementations.

[indutny]

Added "framework" for introducing more benchmarks. Right now comparing to:

• fft
• dsp.js
• fourier

[drom]

try https://github.com/drom/fourier

drom/fourier#1

[indutny]

@drom done

[faroit]

Hey, this is a great implementation!

Have you tested compared to the builtin FFT in web audio? Even though this would be bit unfair because it's not js, it would still be interesting to see if fft.js would be fast enough to use this for realtime audio.

[indutny]

@faroit good idea!

Just curious, how many bands do you actually use in web audio? fft.js can do 2k ops/sec on 16384 bands, which means that it will add less than 0.5ms of latency. On 4096 bands it is about 0.1ms of added latency.

[humphd]

+@corbanbrook who worked on the Firefox Audio stuff with me and wrote dsp.js. He's done a lot of perf work on this stuff in the past, see also https://gist.github.com/corbanbrook/469c325734e458ba1415509f52d9c096

[indutny]

This gist is a part of our discussion with @corbanbrook with regards to fft.js performance and comparing it to dsp.js . After few improvements to benchmarks and the library code, I'm quite confident that current benchmarks are accurate and fft.js outperforms dsp.js on all of input sizes.

[indutny]

Thank you for adding it to this discussion, though!

[Matt-Esch]

https://github.com/Matt-Esch/browser-fft/blob/master/index.js an example using the browser "native" fft with a web audio hack

[indutny]

@Matt-Esch this is cool, however it is rather non obvious how the latency can be measured with WebAudio. I suppose one can insert JS node before and after and calculate delta, but this is obviously not how this is going to be used.

[indutny]

I guess this can be closed now.