Stereo Tool

Aha, clear. It appears that there the majority (probably: all) the processing is done WITHIN the ASIO thread itself, instead of in a different thread. Chances are that the processing is done more 'smoothly', ie. in ST I use a block of - say - 512 samples audio and then do all the processing. Alternatively one could just process sample-by-sample, especially if you don't need/want phase linearity. Or: Split the processing into chunks, and perform a chunk on each ASIO call.

Load balancing over cores cannot really be the issue though, because it must also work on a single core system.

So, contained in the DSP installer, there are TWO versions, one with a /QaxN compiler option and one with a /QxN compiler option?

See page 23 here:

http://cache-www.intel.com/cd/00/00/34/ ... 347599.pdf

No, If you specify both the -ax and -x options (Linux and Mac OS) or the /Qax and /Qx options (Windows), the generic code will only execute on processors compatible with the processor type specified by the -x or /Qx option.
/QaxW /QxW in this case
Try running the SSE2 version on a Pentium 3 and it will fail.
Same for the IPP code: The 'generic' path is not included, only the P4 path.

You're not understanding that when you specify axW, which you *HAVE TO* in order to be compatible with AMD (xW is for Intel only), inside the compiler it will end up making TWO codepaths, one for Intel and one that's "Generic IA-32". At runtime when the software determines that it's not running on an Intel processor, it will choose the "Generic IA-32" path.

Unless you hand-code things to vectorize it yourself, the compiler is going to do things on its' own when it makes the executable that you will not be notified of at all and will not show up as a performance issue on your system or any other Intel system until it runs on a non-Intel system at runtime.

Like I said, I've had experience in the distributed computing community, and nearly all of those projects produce SEPARATE AMD and Intel versions if they are using Intel compilers.

You might do some more research on this before dismissing it out of hand...

I couldn't quickly find it, but this thread is somewhat clear about it:
http://software.intel.com/en-us/forums/ ... hp?t=56928

Basically, /QaxN /QxN compiles for Intel P4, /QaxW /QxW for any SSE2-CPU.

Here's a version with extra logging. Basically, it logs:
- How much time there is between the start of ASIO thread calls
- How much time is spent INSIDE the ASIO thread call.
http://www.stereotool.com/download/radi ... ogging.exe

Log files are written to C:\temp\log (the directory C:\temp must exist!)

Could anyone with cracks (even at big buffer sizes - that's the issue I want to look at with this) run this, reproduce some cracks/pops, and then send the file to me? Thanks!

OK, the W thing has me confused...

What's important is to know if it does anything at all different for non-Intel based on your compiler options. The claim from the Intel employee (bias?) is that QxW would steer non-Intel into SSE2, but the question is, is that SSE2 the same as the SSE2 if run on an Intel CPU? In other words, is there a "Intel SSE2" and a "Generic SSE2", or just "SSE2"?

Also, it's going to matter what version of the compiler you're using.

I've looked into the assembly-code that comes out a lot of times, and I've never seen multiple paths (at least not since I switched to compiling 2 different versions); basically forcing the compiler to create 2 separate versions removes the (not very accurate) determination of which functions should be SSE2-optimized and which shouldn't. So even on an Intel the separate version was about 5% faster (and a few hundred kB smaller).

The code does also contain some SSE2-intrinsics code. For the IPP library - as I mentioned earlier - I'm also only linking the SSE version of ipp 5.x for the ST SSE version and the SSE2 version from 6.x for the ST SSE2 version. (Also including the SSE3 and SSE4 versions only made things slower; code is the same but there's extra overhead to determine which path should be followed and whether the code must be multi-threaded. However, multi-threading is only useful for blocks BIGGER than 4096 samples, so the answer was always 'no' - so I just removed those versions).


By the way: I have created a GCC-build of the command line version some time ago (just before I created the Linux version). On Window, that was about 15% slower than the Intel version - on an Intel CPU, that is...

Not surprising... Likely missing IPP...

I'm going to dig on the W option and how it pertains to AMDs... Like I said earlier, possible goose chase...

On the same subject (compiler options), are you also using O2 or O3?

I've send you a mail with the log file.