Stereo Tool

Could it be that your system doesn't support SSE3?

Not very important though... Unless there is a real advantage to using SSE3 (and I haven't received any response on my question about performance yet).

Question:
- In RMS mode, if you choose a low channel separation, the levels of the channels are merged
- In Peak mode, the peaks per channel are maintained, and the maximum of the merged channels and peaks per channel are used. This is wrong! But, there are 2 possible ways of fixing it:
1. Maintaining peaks per channel. So with peak at +10 on one channel and 0 on the other, channel separation at 20%, the other channel would get +8
2. Averaging and ignoring peak levels; both channels would end up at +5

"2" means that we're adjusting the level based on the total of the left and right channel.
"1" means that we're adjusting the level based on the loudest channel

Which of these methods is correct? Or should both be available?

I used to have a weird combination of these two (method 2 but still using peaks per channel), I've now replaced that by method 1. Question is: Does anyone want to have method 2?

I'm confused here. "Without IPP"????

What I specifically asked you to try was to try a build using the Intel C++ Compiler, requesting SSE3, that was linked to the 7.0 or 7.1 IPP. That combination will not generate SSE3 code for any of the IPP functions because with IPP 7.x, there is no SSE3 support with 32-bit compilations, only with 64-bit.

To directly answer your question to me, no, what you posted was no faster. The problem is that both what I asked you to do, which I more clearly defined above, AND what you just said ("without IPP"), will only give SSE3 code for those parts of the application that do NOT use IPP.

As I understand things, if you issue a SSE3 compile with the following conditions:

- IPP version 7.0.x or 7.1.x
- Static linking WITH dispatching

...what you will get out of IPP are the "w7" optimizations. The w7 optimizations are stated as SSE2.

If you issue a SSE3 compile with the following conditions:

- IPP version 6.1.x
- Static linking WITH dispatching

...what you will get out of IPP are the "t7" optimizations. The t7 optimizations are stated as SSE3.

So, even though my first response to your question is "no", the way that you did the compiling is VERY, VERY, VERY important, specifically the version of IPP that you used. If you did as I requested and used a NEWER IPP, then *ANY* code compiled for 32-bit requesting SSE3 will only get SSE2 out of IPP.

In order to get SSE3 from IPP with a 32-bit build, you MUST use IPP version 6.1.x or lower.

Edit:

Looking around further, I've noticed even older posts from Vladimir and Ying (Intel employees responding in the forum) that are adamant about not supporting optimizations on non-Intel systems. At the time (2004), they insisted the "proper" thing to do was if the CPU was detected as non-Intel, then the "generic" code would be executed. At that time, "generic" meant code path "px", which is C-compliant IA-32. In other words, bog slow.

Bottom line is that I would NOT trust IPP 7.x.x to be AMD-friendly, except for the absolute newest of AMD processors that support SSE4.x. What was done in IPP 7.x.x was very likely their way to circumvent the judicial system that instructed them not to intentionally cripple non-Intel systems.

In the case of example 1, this means that the smaller signal is amplified 8 dB?
In case 2, there remains the channel separation, be even equal in all cases.
Recall that this has on the stereo effect, reducing effect, when the separation is less than 100%.
Nevertheless, I think that option 1 would be the most appropriate and accurate.

_________________
by GAP
"Less is More" (Bob Katz)

I meant without SSE3 in IPP. So the rest of the code can use SSE3 instructions.

Changing IPP linking is a bit more work, and like I said at least on Intel systems there was NO difference at all the last time I tried (using a 6.1 version).

Based on this: http://en.wikipedia.org/wiki/SSE3
one would expect SSE3-supporting code to be faster, at the very least when you're looking at hand-optimized SSE3 code as is present in IPP. But like I said: No difference at all on my system... Which looks a lot like they used the same code for the SSE2 and SSE3 versions. (the SSE4 versions CAN be faster for large blocks of data because then multi-threading is used. However for the sizes that I use, upto 4096, they don't use that and the SSE4 versions are in my measurement equal in performance to the SSE2 versions.)

New version (tonight) will finally have MB median displays again (for the new MB). Should be VERY useful to make good presets.

I am again very confused. Why would you want to run the non-IPP code at SSE3, but have the IPP code be SSE2 or lower? That's not a proper test, in my opinion.

In my opinion, this is what's needed:

- Intel C++ 10.1
- Intel IPP 6.1 (whatever the latest update of 6.1 is), statically linked using the dispatcher.
- SSE3 compilation in C++ compiler, using the option /arch:SSE3 <--- x or ax options may throw non-Intel systems all the way back to 386 code per Agner Fog

* There is a possibility that /arch:SSE3 will fail on AMD systems, but it stands a better chance of generating better performing code than x or ax, per Agner Fog.

* Also per Agner Fog, you may need to override the dispatcher function in Intel C++ Compiler.

I have to go out for a while. BBL...

At channel separation 0% Peek or rms.. less attenuated channel should track more attenuated channel. Simple as that.
Any other way will and it does make problems.

It will either way!. But in one case the total output level will be a bit lower than in the other if the level of the two channels is dofferent

Well.. i did some tests...
And results are interesting.. and in same time bit confusing...

Here is sine test tone with 8dB difference..
http://i.imgur.com/xcxBhVX.png

Now Applyed compressor (rVox)
http://i.imgur.com/Z2f0Kmo.png
Difference is now 3dB.. 0 dB is now -1.4 and -8 is now -4.4.

Now back to original test tone but with one channel lower by 6dB..
http://i.imgur.com/S4Y0cFh.png

Now applying exact same compressor settings
http://i.imgur.com/FTFQ3sY.png

Left channel remains same as in 1st test.. (0 dB is now -1.4 and -8 is now -4.4)

But what is interesting is right channel!
-6 dB is -7.4 and -14dB is -10.4...
So exact same amount of compression but channel is overall lower but exactly -6dB

So i am bit confused.. because that means that 'this' compressor does not share threshold per channel but process them separately as they are both at 0dB at start, but gives same output channel difference at end.