Stereo Tool

I’ll test all the previous versions from version 31 again except version 31C:

Test conditions are:
- Using buffer of 5000ms
- Using priority normal on stereotool.
- Using ASIO buffer granularity of 256 samples.
- Use multiple CPU cores selected.
- Moving windows task manager over the stereo tool window.
- Using prime95 to stress the CPU, priority set to low.

Version 31, 31A, 31B, 31D
- I get clicks
- Also after pressing restart

Now new test with the following changes
- Using buffer of 2,7 ms
- Using priority real-time on stereotool.

Version 31, 31A, 31B
- No clicks
- When pressing restart i get clicks
- When pressing restart again clicks are gone.
Edit: It also does not mather if i select or deselect use multiple CPU core.

Version 31D
- Many clicks.
- Increasing buffer size to 5000 ms does not help.

NEW test changed ASIO buffer granularity to 512 samples.

Test conditions are:
- Using buffer of 5000ms
- Using priority normal on stereotool.
- Using ASIO buffer granularity of 512 samples.
- Use multiple CPU cores selected.
- Moving windows task manager over the stereo tool window.
- Using prime95 to stress the CPU, priority set to low.

Version 31, 31A, 31B, 31D
- I get a click after few seconds
- Also after pressing restart

Now new test with the following changes
- Using buffer of 5,4 ms because otherwise i get clicks note: (2x2,7ms).
- Using priority real-time on stereotool.

Version 31, 31A, 31B, 31D
- No clicks but not always so it could start with clicks or not.
- When pressing restart i get clicks but not always.
- When pressing restart again: clicks are gone but not always.

I think this is important:
Sometimes i get no clicks when pressing restart but after pressing restart a few times, i can see that the buffer is not filled to the max anymore. Then the clicking appears when i move the window.

Things are getting very weird... Anyway, here's a fix for the issues in 31E - hangups (Bojcha) and bigger buffer size in multicore mode (eldoradofm) should be gone now.
http://www.stereotool.com/download/radi ... 1-031F.exe

This doesn't fix anything else yet though. I'll respond to some other posts which contain interesting info in a moment.

EldoradoFM:
Thanks a lot for your feedback!
- So you get MORE clicks at buffer granularity 512 than 256?!
- So far I have never seen the situation that the buffer is not filled to the max. That would explain a lot (because basically it corresponds to having a smaller buffer size). I've checked the code and I found some 'suspicious' code - fixed it, will put a new version online soon. For now, when I do, the only thing I need to know is: Does this (buffer not filled to the max) still occur? So that should be very easy to test....

Hm, I can tell you that there is at least the following:

- One driver thread that calls Stereo Tool to 'swap buffers'. Basically, a package of samples is delivered to Stereo Tool, and simultaneously, Stereo Tool sends a package of samples back to the driver.
- One processing thread in Stereo Tool. This gets 'woken up' when samples have arrived, collects them, and if enough samples have been collected, processes them. This takes several ms (depending on processing setting), and could potentially interfere with the first (driver) thread if that has a lower or equal priority. The priority of this thread is 'Normal' (7), or 'Time Critical' (15) if 'high' is selected in Stereo Tool, or 'RealTime/Time Critical' (31) if Realtime is selected in Stereo Tool. If you select Normal in Stereo Tool and Realtime in Task Manager, it's RealTime/Normal (23).
- If multicore processing is enabled: An extra thread, same priority as the previous one, that adds the FM MPX signal and - if enabled - performs composite limiting.
- There's also a thread (priority Normal) that performs GUI updates.
- And finally there's a thread that processes Windows messages (mouse clicks etc.), also at priority Normal.

Now:
- I don't know why there are 2 ASIO4ALL threads. (Most likely one - that with the highest priority? - is the actual processing thread, the other one is the rest of the ASIO4ALL stuff).
- I read somewhere that ASIO4ALL uses a new mechanism in Windows Vista/7 to raise the priority, HOWEVER IF THE CPU LOAD GETS ABOVE 80% IT GETS REDUCED TO NORMAL PRIORITY. What is your CPU load?

I've seen that there are some other applications that change the priority of the ASIO driver thread... That seems a bit risky, but apparently it's sometimes needed. So that MIGHT be the solution here. Unfortunately, setting the priority myself will interfere with this new Windows Vista/7 mechanism, so I'd like to avoid it if possible.


"ASIO threads are dumped and new one created every few(5-6) seconds." - Wild guess: ASIO4ALL detects that there is something wrong (due to all the clicks, which it can detect because the function doesn't return in time) and restarts the thread.

eldoradofm:
http://www.stereotool.com/download/radi ... 1-031G.exe

Could you check if the issue with buffer that are not completely full after hitting RESET is gone?
I've made some changes - turned out that I started the ASIO thread BEFORE I configured which channels are enabled and which are disabled. Now I would expect the thread not to kick in that soon - but if it does it could do something like that.

Edit: Odd, first startup behavior is wrong again. After hitting RESET it seems ok...
Edit #2: Cause found, after first RESET everything should be ok - before it's not.

My problem is that all this betas works good on my pc. At other one is totally different story.
Difference at that AMD PC and my INTEL is so big.

I know. My problem is that on my pc everything works fine also. So I cannot reproduce any of this. Basically, it seems that the cause is in the ASIO drivers, not so much in the PC (although a quad-core will probably have no issues either).

What kind of processor do you have?

Tested with version 31G. This is what i get when hitting RESET and then loading the preset i use for FM and then hitting RESTART a couple of times.