Stereo Tool

Thanks! I can confirm now that it's indeed the ASIO thread that doesn't get called in time.

I'm logging 2 things:
- Duration of execution of ASIO thread code
- Time since last ASIO thread call
Both in CPU cycles.

At the start of your log file, where you say there's no clicking, both look very constant:

46442 3924448 0.000000
45452 3905330 0.000000
54351 3913437 0.000000
25938 3899632 0.000000
46277 3924877 0.000000
45617 3906947 0.000000
53680 3912161 0.000000
25971 3898752 0.000000
48202 3927253 0.000000
46244 3907442 0.000000
54901 3924943 0.000000
26235 3885563 0.000000
46750 3924899 0.000000
45001 3905968 0.000000
53438 3914592 0.000000
26125 3899005 0.000000
46178 3923700 0.000000
45122 3906683 0.000000
53053 3914493 0.000000
...

So basically, the thread gets called approximately every 3900000 CPU cycles.

But at the end of your log file, after hitting RESET a few times, where you get horrible clicking, it looks like this:

103862 3932830 0.000000
123849 7810099 0.000000
30591 162118 0.000000
97845 3759701 0.000000
119867 3926252 0.000000
114433 7861282 0.000000
29227 151547 0.000000
86955 3693800 0.000000
131560 3934524 0.000000
127754 8518840 0.000000
34188 163779 0.000000
127270 3032128 0.000000
137291 3946074 0.000000
163471 7605521 0.000000
27621 190795 0.000000
79585 3892350 0.000000
103840 3903460 0.000000
92609 7513396 0.000000
40194 720731 0.000000
89419 3506778 0.000000

As you can see, the time between calls often reaches or even exceeds twice the time it should have taken (3900000), which means that the data should have already been sent back to the sound card at the moment when it's called. So I start filling the ASIO buffers *after* they have been sent to the sound card, resulting in pops and clicks.

The execution time also jitters more, but that's not really relevant (it takes longer, but not by far long enough to explain the time between calls).

Question: Was this with less full buffers, or not? (I don't think it has anything to do with it, but since I'm still looking for the cause I cannot be certain...)


Maybe a strange request, but could you check what happens if you set the Stereo Tool priority in Task Manager at Below Normal or Idle, when you're already having clicks (Stereo Tool internally set to Normal)? I'm just curious if the ASIO thread responds to that or not.

No, the buffer seems to be full when i tested this with 5000 ms buffer.
EDIT: This testing was done with stereotool set to Real-time.

Testing now with priority set internally to normal in stereotool, it's much harder to get clicks with buffer of 5000ms.

Hans, I consulted a former senior colleaugue of mine at Citrix. He confirmed what Brian says. Even in ver 11 of Intel Compiler, the dispatcher looks for alternate code paths and more specifically for Genuine Intel string. To prove he's right, he actually showed me that a simple C++ code for generating primes from 1to 10000 takes 5.6 seconds (with SSE2 optimization) on AMD Phenom II X4 965 and the same code takes 1.57 secs on Intel Core II 8400...ridiculous! Now same C++ code compiled with MinGW GCC (optimized for AMD with SSE3) takes 1.53 secs on the same Phenom processor...
Ii am checking for some tool that alters CPUID for VMs
Here's a snapshot of StereoTool, latest beta(compiled with icl):

_________________
visit website

Tested this with buffer of 30 ms.
I noticed the following:

When i get the clicking on Real-time set in stereotool. And then change it to normal in stereotool. Then it's pretty hard to get clicks again by moving windows around.

So i change it back to real-time in stereotool, i get the clicks again.
Then i hit restart, so not reset but restart, clicks are gone. Then i select Normal in stereotool, and when i then move screens around i get clicks.

So which version do you want me to test at below normal or idle, the one with the clicking at normal or the one with the clicking at Real-time?

I don't really know... At least keep Stereo Tool's internal setting at Normal - that way the processing threads don't get a boost in priority.

So I would say: Set ST to Normal, hit RESTART until you get clicks (or reproduce them the way you describe above if that doesn't work), then in Task Manager set priority to IDLE or BELOW_NORMAL.

Hm, surprising that that code is there. I still expect the code to run the same on an AMD though, because when I removed the 'generic' path from the executable it shrunk about 20% in size - so there shouldn't be a generic path. Also, any manually optimized SSE2 code is definitely in there (because I used #ifdef 's for that).

Having said that, the result of a test with this check bypassed (as you were looking for) would definitely be very interesting. Just to make sure.

Tested it still clicks, seems to be the same amount as with normal. Tested with buffer of 5000 ms.

Good, I might have an idea then.

If I'm right, it shouldn't matter at all at which priority you set the Stereo Tool process, as long as it's not REALTIME.


It seems that the ASIO thread gets Normal priority WITHIN THE PROCESS. So if the priority OF THE PROCESS happens to be higher, then the ASIO thread also gets a (relatively) higher priority.

Now what I need is that the other threads get a priority that is HIGHER than that of other processes, but LOWER than the ASIO thread.

Or:
- Stereo Tool PROCESS priority to High
- Processing thread priorities to below_normal
- GUI thread priority to IDLE

Something like that.


See http://msdn.microsoft.com/en-us/library ... 85%29.aspx .

Normal priority threads in normal priority processes have priority '8'.

If I change the process priority to HIGH (HIGH_PRIORITY_CLASS), That is '13' instead.
Then I can set the processing threads to BELOW_NORMAL - '12'
And the GUI thread to LOWEST - '11'

(ABOVE_NORMAL for the process might be better, GUI thread is then at priority NORMAL).

radio_tool_SA_BETA601-031H-logging
AMD Athlon X2 5600+ 3,3Hz 2x1GB ddr2 1000MHz - Juli@ 192kHz / 256 samples / ST 4096 Latency - FM output

Hans, you gonna love this....
The 3 files are: PrimeSSE3Intel(/Qx:SSE3), PrimeSSE3Generic(/arch:SSE3) and the 3rd(PrimeSSE3Altered) is patched PrimeSSE3Intel !
Tell you more: Patched Stereo Tool and now 5ms buffer , 128 samples latency(44.1KHz), Normal Output, Normal Priority in VM. No drops!

_________________
visit website