Stereo Tool

The stand alone build failed unfortunately. And I have no time to build it again now.
Winamp DSP: http://www.stereotool.com/download/dsp_ ... 04-047.exe
VST: http://www.stereotool.com/download/vst_ ... 04-047.dll
STAND ALONE: http://www.stereotool.com/download/ster ... 4-047A.exe

I think I've found it, if I'm right the key would be saved if you send Stereo Tool to the icon tray directly after registering (but it could potentially fail in some cases even if you do that).

Just did a measurement, with Burst protection disabled the CPU load of the old and new version are identical; if I load PhantomFM's Big O V2 preset and enable Burst protection, the total CPU load of BETA047 is 4% lower than that of BETA045. Lookahead wasn't present yet in BETA045 so I couldn't compare that, but it has nearly no effect on the CPU load.

Checked it, and at first I found the same thing. Then I tested it without 'multicore' enabled, and then I see the opposite: CPU load at 512 is actually (slightly) lower than at 4096.

My measurement results:

      Phantom Big O V2
      |  Same with no declipper and old MB
      |  |                 First without multicore (twice as much time, number between () is adjusted for that):
4096: 50 (66)         54   No MULTICORE:  62 (31)
2048: 50 (70)         54
1024: 47 (63)         51
 512: 44 (63) (no dc: 49)                 65.5 (33)

          4096 2048 1024  512
CLIPPER:    37   41   40   45 (Logisch)
DECLIPPER:  34   34   35   33
NEW MB:     68   68   66   62 (No multicore: 44 for 512, 41 for 4096)

My conclusion: If the latency is smaller, it happens far more often (4096/512 = 8 times more) that the code needs to wait for all the created threads to finish.
And this hurts the thoughput (although it's still a lot higher than without using multicore, for 4096 the throughput increases by 50 / 31 = 61 %, for 512 that's 44 / 33 =
(the forum software is acting up, I cannot type the result or it refuses to let me post! thirty-three %).

Just added a stand alone build to the post above. It's slightly different from the other 2 (registering issue should be fixed and the Limit slider responds 100 times faster to mouse wheel/drag/keyboard input).

About the Quality slider: No, much processing works on blocks of audio (hence the latency setting) and they overlap. If you reduce the overlap, you'll get steeper slopes on the sides, which means that there will be some effects mainly to low frequency sounds (blob-blob-blob sound or wobbling effect as it is called by some people here on the forum). You'll hear it for example if you play a low frequency (say, 50 Hz) sine wave and use the phase linear highpass filter.

To get a perfect output, the overlap should be 75% - in other words every sample should be processed 4 times.

Unfortunately, in Stereo Tool the overlap is only 50% - every sample is processed twice. That's what causes this effect.

If you reduce the overlap further (by lowering the slider), the effect gets worse because the overlap is reduced further. It will get both bigger in amplitude and higher in frequency.
But... Then I would expect the CPU load to drop a lot if you lower the latency. At a latency of 512, the memory usage would - for most things, agreed, not for everything - be 1/8th of the memory usage at 4096! (The memory is still allocated because in a real-time program you don't want to dynamically allocate and free memory, but most of it just won't be used - hence also not be cached).

Now it could be that it does drop - to test that disable 'multicore' as I've seen earlier today that it has less effect at lower latency settings. Also, please disable the Advanced Clipper since it behaves differently at different latency settings - most other filters don't.

That's indeed not there yet. I'm not sure if it's needed - or for what it would be needed/useful.

I've noticed that some tracks, in places where stop playing the bass and mids grow excessively, it generates a spectral unbalance is remarkable, the same happens in the highs. Mainly this happens when using many bands in the MB.
It would help to not fire any band more than necessary and its adjacent spectral generate an unbalance in the soft passages is more noticeable.
Do not you think the rest.

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

@Hans:
consultation, by using the look-ahead, if using different time values ​​per band is delayed one more time or another affects only the anticipation of control?

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

The multicore option should have logic in it to bypass / ignore the setting if the current system tests as a single-core system. The only tricky case would be Pentium 4 processors that have Hyper-Threading.

At any rate, on my single-core system:

CPU load with multicore disabled on a "generic"-style preset @ 1024 @ 100 quality with declipper ~= 20
Same @ 2048 ~= 10

CPU load with multicore enabled using same preset @ 1024 ~= 20
Same @ 2048 ~=10

Tests at 512 were ~= 38.

Edit: Without declipper, load at 512 is "0", and at 1024 it is also "0". 2048 pushes it up to 8.

As you can see, everything is identical, with or without multicore, which is how it should be on a single-core, non-HTT system. Your processor has Hyper-Threading, so even if you only use a single physical core, the OS can address it as two logical cores.

Don't know why you have differing results, but here's some speculation:

The values I'm giving you are obtained by observing Task Manager or Process Explorer. I'm not sure how reliable your "time to process" testing methodology is. If it relies on data being written to disk, then you're adding in another component, and you'd have interfering metrics such as rotational speed, cache, access times, fragmentation, buffered (cached) writes vs. unbuffered, etc...