Details

This task is a placeholder for my frequency analyzer work. In its current state, it should build on almost all targets (it will try at least - it doesn't do any feature checks - I am not sure what to check for.. ).

I tried the file from http://www.freesound.org/samplesViewSingle.php?id=22714 (also attached), and I seem to get randomly distributed lines. I'd expect a single line moving from left to right (or multiple ones, depending on sampling speed, but still very grouped). Am I misunderstanding things, or is this a bug? This is on gigabeat F

So, it turns out, the math in the previous patch was all messed up. This version works as expected.

Due to the low number of samples the FFT has to work with (merely 1024 samples per channel), the results are less than optimal (the simulator tends to become unusable with N > 2048; I am yet to investigate the behavior on target).

The freeze bug has not been fixed but who knows, all the rework that was put in might have fixed it.

Next on my TODO list: logarithmic scaling. After that come the pretty colors. Only then can I start work on the spectrogram mode.

I did initial review of my math and changed the way the code handled 32-bit overflows. Now, it does a 64-bit (s47.16) sqrt and then clips the value to the s15.16-bit range needed for the fixed-point logarithm. Not the most elegant of solutions and certainly quite CPU-intensive (all the 64-bit math in fsqrt64, in particular) but good enough for the time being.

The target refresh rate is now configured on a per-mode basis - this needs testing to find the optimal values for each platform.
The plugin now unboosts the CPU on exiting (sorry about that, I somehow missed it).
Fixed spectrogram mode on 320x240 screens (other sizes possibly affected, too; there were some spikes every 8 or so rows).

I began making the bitmaps external, though that is going to take some time. Right now, there are only 320x240 and 160x128 bitmaps. I need advice - do I keep the entire image as a bitmap or do I keep just one line and blit it over and over again?

Most importantly, there is initial work on greylib support though that is proving kind of hard, any and all help on this part will be appreciated.

It's been a long time but I actually want to get this done and possibly committed, so here goes the next patch:

Changes:
- Make the code multi-threaded (needs some work in this area) - shouldn't make playback skip now
- Greylib support - should work on targets with greyscale screens
- Use LUTs for the window function coefficients - should have speeded things up a bit
- Bumped the transform size up to 4096 for the time being (can be from 512 up to 8192 - those are the only tables I've generated) - this is a bit too much for PP devices but I'm looking for feedback from beast users
- Switch to a kiss_fftr for the transform (i.e. do things properly :) )
- Dropped colored mode - wasn't particularly useful or pretty - requires just one bitmap now - the one with the colors

TODO:
- Add a few more keymaps (can someone help me make proper keymaps? I kinda did them randomly when I started)
- Take a stab at the post-transform math - this needs to be rewritten - all help will be appreciated.
- No precompiled transform size? (this is actually quite difficult)
- Cleanup the kiss_fft code - there are radix-3 and -5 butterflies in there - we'll never use those..

- Apparently, some targets don't have enough data in their peak buffer to do a 4096 transform. Hence, lower the buffer size to 2048 samples
- Use the second core on dual core targets
- Split the LUTs into multiple lines

Again, use "git apply" or see the previous post for instructions regarding the color map.

Out of interest, how does the performance of the kiss_fft compare to the fft in the mdctexp branch of svn (currently in apps/codecs/lib/fft-ffmpeg) ?

Ideally we would want to encourage code reuse across the codebase - one fft available to both plugins and codecs as necessary - and it should make sense to ensure that the choice of fft is optimal in each case. We're currently evaluating a derivative of the ffmpeg fft code, for codec use (as part of the imdct used for transform codecs like mp3, vorbis). See page FasterMDCT on the wiki for more details.

Dave, kiss fft is undoubtedly slower than the library in the new branch. However, the speed of the fft library is not the bottleneck here. What's limiting the speed of the plugin is the availability of pcm data.

I am currently trying to improve the way it's getting the data in order to reduce polling (or eliminate it entirely) and hopefully increase the speed a bit. However, I'm not too optimistic as each target apparently has its own peak buffer with its own size (the reason some targets can't do a 4096 transform). That is, at the end of the day, you only have so much data and the speed of the fft is not going to be that much of an issue.

I agree that it can and should eventually be optimized but right now I'm not touching it.

Hi again,
I finally managed to compile the v8.patch.
Runs with no problems on my iRiver h120. May I ask if it will be possible in future versions to have also realtime FFT analysis on Mic and Line input ?

I'm recording a lot with the iRiver and such a feature would be really handy.
I'm also interested in testing future versions when available.

nofish, that can be done relatively easily, though I don't have a target to test it on. I also don't have the time to put into this plugin.

Thus, I would like to request that this plugin is committed as the changes I had envisioned proved much too time-consuming and difficult. This is the best I can do without touching the core. Of course, KISS FFT can be improved (or even replaced with a better implementation) but that's an insignificant improvement.

If someone is willing to go over the keymaps (I have no experience with keymaps and just hacked together a few keymaps - experience has shown that, except for iPods, they're horrible), I think this can safely be committed.

In any case, I really don't have the time for it any more and would hate to see it die in the FS graveyard. :)