Stereo Tool

Good! I have no idea why but it's good that they are gone now. I just hope they won't come back!
I see it, I thought I had fixed that (in the first version these things were always displayed), will check what's wrong!
Which version (stand alone, VST, DSP)?, and how did you test this? If this happened everywhere it would sound horrible...
It works fine here now (and before I got silence as well). Can you tell me *exactly* what you are doing? And what you see (what happens to the buffer filling, and are the 2 numbers showing speedup etc. staying at x1.0000?)
Missing a break in some mode, will fix it.
True, I didn't think anyone would be using it anymore, especially after the latest performance improvements...
I'll run a 'generic' build, but I expect things to be a whole lot slower.

Test like all versions. generator-> virtual cable-> ST
It`s the Stand Alone version... tested beta 53 and no any of this! but beta 54 is like the picture.
Yeah it`s horrible .
Here is the beta53 .. Clean !
P.S: Shadow in the output is from wave shaking from my video already show you.

I tried, and even my i7 can barely handle this version. So unless you think your k8 is faster than an i7 this is useless...

Could this be somehow related to the sound card synchronization? I don't know... But almost nothing happens on the input so this is really strange.

Just checking: Input left/right is identical? I did optimize something a bit in this last version.

Yepp....
it`s from the optimization of synchronization.. If i disable it . it`s gone, but beta 53 is OK. So you may be optimize something more than needed
You mean that this is not appear to you ? and everything is ok ?
I knew that AMD is more precise for finding errors AAAnd here we go .Error is fact and Intel not recognize it ? Just wonder why is that difference ?!!?
I told you months ago to try compile some betas with AMD libraries just think that you`ll be more happy .
May be i`m wrong on this but.... don`t know ...

After you said you'd do a generic build, I wanted to reply to make sure I clarified things a bit more, but I didn't have a chance to do that until now.

Also, I'd like to make absolutely sure that you understand that what I'm trying to test here isn't exclusively for K8, but would apply for all AMD processors, even a brand new one bought today, so long as you're using the 10.1 compiler.

So, no, I don't think a k8 would be better than an i7 on straight FPU code. That said though, I may have had you underperform too much.

From what I understand, by reading Agner Fog's blog (nice rhyme, eh?), and reading pages 132-137 of this document:

http://www.agner.org/optimize/optimizing_cpp.pdf

... the Intel C++ Compiler does not treat non-Intel processors fairly, while the IPP libraries (at least through 6.1) do treat non-Intel fairly. What I was trying to have you do was a compiler test, but not both the compiler and IPP. Yeah, I know I was just complaining about mixed-case situations, but it is exactly that which I'm trying to test for, i.e. if you request a SSE2 build from the compiler and IPP, IPP will give SSE2, but the compiler may not.

So, based on your previous comments, I gather it is possible to set the compiler different from IPP. What I'm most curious about, and again bear in mind that this applies to all AMD systems, not just the older K8, is if the 10.1 compiler is treating us fairly.

Also, you should be fully aware that your i7 will indeed see a performance degradation by setting up generic IA-32 for the compiler, but SSE2 for IPP. That would be completely normal. My testing here however is not for Intel systems, but for AMD systems. Your Intel system gets treated fairly by the 10.1 compiler. Forcing the level for you lower is what may be automatically happening to those of us on AMD processors, and you have no way to test for or ever see it happen.

Does that make more sense to you now, and do you see why it is of larger scope than just me and my system?

That's what I'm trying to accomplish with my discussions. Framewave and the AMCL may be close enough to the performance of Intel C++ 10.1 and IPP, and it removes this wonky "Is the compiler doing something behind the scenes?" stuff out of play.

On the other hand, Framewave could be absolutely horrific. The thing is though, without trying, there's no way to know.

The other thing is, Framewave is FREE, while the Intel stuff you have to pay for. Maybe you do indeed "get what you pay for", but again, without trying, there's know way to know.

Just discovered that additional bass "shaking" also comes from EQ

Yes, nothing surprising
Hans said that he know about this and know what to do with it and fix it , but later...
It`s something in the code of the filter, but i don`t understand why it appears only in bass ?! may be it`s not noticeable in the high frq`s ( i don`t know but i`m not able to see it) . So we will wait for it... I believe that Hans know how to fix it ,so it will be...
I found also interesting thing that if i set coupling to 100% ( nevermind beta 53 or 54...) shaking is almost gone. Don`t know why is that... But it looks like the level is overloaded and the filter do this strange things ? It only looks like this , i don`t know the actual reason !

Yes, but this is not happening in my code. Simply because I don't use the dispatcher (except in the command line version). I used to a VERY long time ago (probably version 3.xx or so) but I then discovered that - even on the P4 I had at the time - the dispatching itself and the determination in the compiler whether it should produce multiple versions of a function doesn't work very well; by only allowing one code path (SSE2) I got a performance increase of about 10%.

So there is only one code path, and it either works or crashes if the CPU doesn't support SSE2.

There is also an SSE version (not for the beta's though); the installer checks which of the two you need.