Stereo Tool

@Storm905: Probably related to the 5.1 support that I added - I'll try to reproduce it.

Something doesn't make sense here - max freq = 400 but in the graph it goes only to 200... I don't see any gap at 400 Hz, but I did indeed see one at 2800-3000 Hz - that's fixed now (next version; tonight).

Stand alone: http://www.stereotool.com/download/ster ... 02-004.exe
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 02-004.exe
VST: http://www.stereotool.com/download/vst_ ... 02-004.dll

Done:
- Fixed RDS characters > ASCII 127 encoding (I hope)
- Removed hole in sweep at 2800-3000 Hz
- Changed installers (removed non-SSE2 versions, replaced them by opening a different download page), compressed binaries. Winamp installer no longer installs in Plugins/ if that directory doesn't exist yet.

TODO:
- RDS special characters conversion
- Check channel swap when loading a preset (just managed to reproduce it by loading built-in presets; my debug version crashes when this happens which helps )
- Scrolling issue if there's no scroll bar.

That's the point. It goes even lower then 200Hz if 1st slider is lower. However, with "pink noise" things are totally different. there IS BIG gap just under 400Hz.
Yea gap around 3kHz is gone, but also gap around 400Hz is almost gone.

@Hans

Way out of left field advanced question:

Does any of your code generate 128-bit SSE/SSE2 instructions?

Yes, why?

Because I've done some more digging and have a possible reason why you see different CPU load changes than I do, including how you said that you didn't see much benefit from reducing the number of extra calculations.

If the instructions are double-precision, K8, which is Athlon64 and Athlon64 X2, only has a 64-bit wide SSE pathway. To handle 128-bit DP instructions, the K8 core has to split the instruction in half and process the halves. This means that 128-bit DP instructions coming into the pipeline may encounter a split-process-reassemble chain.

So, in addition to the 128-bit, are the numbers also double-precision? That ties back to the post on the Intel forum, btw, and may include whatever IPP calls you use.

These very detailed architectural differences can't really be compensated for by reducing the number of cores you have running or slowing the processor down, as your Core2 system handles SSE(x) very differently internally, to the point of where you'd have to be able to manipulate the performance of a Core2 system down to the XMM / SSE register level.

Bottom line here: Not requesting you rewrite to only generate 64-bit chunks, but just requesting you re-examine removing the unneeded steps in the various filters, because for every 1 unneeded step, K8 may be taking up to 3 unneeded steps (split-process-process-combine vs. process).

Hm interesting. But nearly everything uses 32-bit floats - are they handled normally? For those unnecessary steps, I'm using 32-bit ints (SSE2 optimized). Most interesting would be the behavior of this call: _mm_shuffle_epi32(). Except for that, all I do is reads, writes ands and ors.

Actually, this could mean that a non-SSE version might run faster on AMD's! (Although I doubt it; the difference in performance if I switch SSE off in the compiler is pretty big). But the Intel compiler often does everything with SSE2 registers because they are faster - even if it needs to do only a single calculation. Now if the AMD would still perform multiple calculations in that case it might in fact be slower!

I think I've fixed it. And this cannot have been new - must have been present in all versions since 6.something!
If it still goes wrong now, loading another preset will no longer fix it!

Maybe I've missed somebody mention this but I appear to have a problem when switching between presets in that the FM output buffer seems to deplete a bit after each change until it's empty?
(No more green area) Changing the buffer size slightly seems to refill it.

Strangely, the Normal and LQ outputs (ASIO out on the same card but using different channels) don't seem to exhibit this sort of behaviour?

I was testing using VAC as the input if this makes a difference?

On a different note, when looking at the multiband again, would it be possible to implement a 'solo band' feature? It might be easier to know where to tweak if you could hear individual bands by themselves?