Running the un-modified code under the DIY-KeK posted Aboriginal Linux using the DIY-KeK qemu-1.1.1 build; limited to a single cpucore - - -
Build notes:
Code:
(armv6l:1) fft-arm-0.01 # export CFLAGS="-O2 -march=armv6 -mfpu=vfp -mfloat-abi=softfp -fomit-frame-pointer"
(armv6l:1) fft-arm-0.01 # gcc $CFLAGS -o ffttest-arm radix4fft.c testfft.c testmain.c -lm
(armv6l:1) fft-arm-0.01 # strip --strip-unneeded ffttest-arm
(armv6l:1) fft-arm-0.01 # ls -l fft*
-rw------- 1 guest guest 1959 Apr 17 2004 fft.h
-rwxr-xr-x 1 root root 14068 Jul 17 12:08 ffttest-arm
Yields a test run of:
Code:
(armv6l:1) fft-arm-0.01 # ./ffttest-arm
Testing a 64-point FFT.
1:1 mapping; no reorder required.
SNR: 14167370.493333 (71.512893 dB)
Mean energy in: 0.989857 out_test: 0.989554 out_ref: 0.989579
Timing FFT speed...
5.87 us per 64-point FFT, or 21.80 Mbps with QPSK, or 20.29 insns per point on a 220MHz SA-1100.
NOTE: That hard coded machine type lies, this is an emulated armv6l running at 300MHz.
Seems like we could run one of those, with the most recent set of samples taken from the audio stream buffer, just before each e-ink update. Even at a blazing e-ink update rate of 15fps.
I.E: Adding another 6 us in front of each e-ink update to display a rt, graphic, equalizer with a spectral display isn't going to be noticeable - not even to the processor.
Let us see what the resource usage is when run as a stand-alone program (rather than hard coded into the equalizer):
Code:
(armv6l:1) fft-arm-0.01 # time ./ffttest-arm
Testing a 64-point FFT.
1:1 mapping; no reorder required.
SNR: 14167370.493333 (71.512893 dB)
Mean energy in: 0.989857 out_test: 0.989554 out_ref: 0.989579
Timing FFT speed...
5.90 us per 64-point FFT, or 21.71 Mbps with QPSK, or 20.38 insns per point on a 220MHz SA-1100.
real 0m 0.76s
user 0m 0.75s
sys 0m 0.01s
Hmm...
1 fps isn't going to keep up with a 15 (or 7) fps display.
Maybe hard coding the look-up tables ...