boring..
show me fft code
Never realized I am here to entertain you
anyways clearly I am not going to recreate the wheel
github.com/projectNe10/Ne10/blob/master/modules/dsp/NE10_fft_int16.c
which is BSD-3 license so we can link the .so and use it, I already tested it under emulation and it's one of the fastest and most precise fft implantation
their idea of summing and shifting right by 3 (because we got 8's, and their weight per channel is 1/8, so shifting by 3 is like dividing by 8) is really fast
it does lead inprecise complex to complex, it's more general purpose, but we don't really need complex dimension when we are dealing with sound waves...
I thought I was clear that I am going to base fft and ifft on ne10 on my previous post, when god offers you a fast library that you can hardly fight and you will most likely copy most of your code off from them, use it, the more 3rd party support we get (which will constantly update) which resolves our issues exactly, the better.
the idea will be that the above code that I posted will be fast 48->96 transform (which is as fast as about 2ms-4ms compute per second of audio sample, that's as fast as my 9900k does natively, which is overclocked to 5.3GHz with custom watercooling, so it says a lot) , levi's code will be fast 44.1 ->96 (when I will neonize it, which seems easy enough) and ne10's-based fft, transform and ifft will be audiophile mode (which will work from any sample rate to any sample rate)
the only question is what filter I will apply on the frequency channel once I fft it, butter low seems really cool when I tested it out, you can easily do with numpy (NE10 is here only to do it faster, we can test our theory on python offline easily to make sure we are right, if we can't do it in python using that method we OBVIOUSLY can't do it in C)
I also wrote FXAA for neon, and since neon offers quick int->float->int vector conversion, it was REALLY fast scoring about 7ms for 44.1 -> 96 per second of audio, and really precise, but it missed reoccuring waves that differ in chunks, I found a way to overcome this by changing the factors between inputs shaders and output shaders, which clearly doesn't affect compute time and leads to better results, the question is which ones are more right