Stereo Tool

Hans,

For me not a big difference in CPU load, but low latency artifacts seems somewhat better.
(less cracle with superlow asio latency)
@ Hans, whats next ??

_________________
----------------------------------------------------------------------------
AIRCHAIN-GURU professional independant airchain consultancy.
Orban/Omnia/Vorsis/DSPX/Aphex/Inovonics
----------------------------------------------------------------------------

You really want to know?

@Hans

If your code uses error codes / retun codes / status codes and checks them with If statements, exception handling, specifically the "zero-cost" model, would likely speed up the code because of the following:

- There is overhead to checking error codes, specifically that "If" statements introduce a potential branch. This adds entries into the processor's branch prediction tables and the historical "branch taken" tracking data required is higher.

- Due to having to keep track of more potential branches, less cache space is available for either data, instructions, or both. You will note that previous performance discussions indicated a cross-architecture performance tipping point at 1MB or less per core. This accounts for the following processors: P4, Pentium D, Athlon 64 (all skus based on K8), and Pentium Dual-Core (all skus up to and including those based on Merom-M and Merom-L). Merom is a "Core microarchitecture" processor, with half of the cache disabled. You'll probably find a LOT of those around with budget-constrained DJs who have older laptops.

What the "zero-cost" exception model does is makes code size larger, as it stores a table with exception information in with the rest of the compiled code. However, it has the following benefits:

- Extremely minimal or no performance penalty if the code executes without error. This is because it doesn't load in the exception bookeeping code when a try is encountered and only loads it if the code errors and the catch is hit.

- Frees up branch prediction table entries and backing cache entries that were formerly used for error code checking.

- If there are no exceptions, it is entirely possible that the exception table will not get loaded, but sit on disk, thus decreasing total RAM usage.

****

As for the Core Solo and Core Duo line, they have fewer floating point units than full-fledged Core2 models. This is another spot where profiling would likely help, along with the discussion about the code vectorization that you had on the Intel forum.

YES!

Next i want some one to tell me why on Normal Output no sound ?
Only me or someone else is having same problem ? This is on latest beta 42 Stand alone

All ok with normal output http://85.25.73.243:10680/listen.pls

Same here, can set it to lower latency without stuttering/ crackles ( up to 60ms lower @ 192 khz/4096samples/ jeroen 9 band preset)

Just found a really big bug in the compressor implementation - this was causing Attack to behave differently from how it should behave. Attack could actually lower the level to BELOW the target level..... And hence also worked too fast. Will be fixed in tonight's build.

I think this really big bug is in the new MB bands too.
level must be auto leveled to the threshold level set by user.. not by 0 db ?!
I mean after the Drive ..... because if we set a big drive db`s , sound goes huge saturated , Look also new MB for this bug Hans

It seems to me that the multicore support for the DSP version of Beta 42 is false (inverted) at least for the new multiband.
If I enable multicore then I get a much higher CPU usage in WTM than without (no Declipper, no Advanced Clipper - only the new Multiband with 9 bands).