hello again
thx LBH for your attention.
first, as i understood, ASIOGUARD is a mechanism that increase buffer size for tracks or vsti's that aren't in monitoring mode(no need to be played in realtime) it allows precalculate bigger chunk of audio before spit it out . thats why when monitoring is off, peak load is lowered. its a real benefit. when asioguard is disabled, peak load stay at the same level(higher).whenever track monitoring turned on or off.
Second, the processor is overclocked here. Cooling system is a custom EKWB loop. yes it's over the stock speed. But don't expect obtain fantastic result for achieve low latency with stock settings.
Intel SPEEDSTEP is disabled and all cores are running at the same speed. that means that every core stay in sync at 4,7 ghz .that means there no switching of frequency clocks. its a very good thing because switching core frequency clocks can cause dropouts when buffers are very low.
throttling can occurs only when alls core are at 100% when running a program like OCCT or a heavy duty CPU based rendering program like Blender. in this case throttling don't even exceed 1%. I project to delid and repast the proc soon to get rid of that.
In DAW context, i had running some tests: at least 250 tracks of reading/recording stereo channels , realtime processing.... bunch of VSTi's still at minimum latency, At 96kHz( lots of plugins sound drastically better in 96khz, like KORGS , NI's D16 and others) without blinking an eye. i experienced KONTAKT had achieving a least 4000 voices ....
no, We can't really blame here overclocking.
So..
see on screenshot 3: you can read temperatures of the system: processor temperature here is ok at 42 Celsius degree for a cpu load at 42%. Ambient temp is at 25. Water at 29.
but look attentively: here we are running AND PLAYING 12 INSTANCES of MONOPHONIC BUCHLA with
minimum latency, in 96kHz ! it's not bad at all. considering the Bulcha is sounding very analogue, i suppose its calculations are very cpu consuming.
In this case, each instance CPU consumption of the buchla is distributed equally on each logical core used by NUENDO.
Its fine in this case
but look now on screenshot 5: only one instance in polyphonic mode (just only 4 voices) put all 14 cores used by nuendo abnormally loaded... causes sound grungelized( not really spikes and pops). on the task manager graph it seems that the CPU load is not divided equally between the logic cores but REPLICATED !
something definitively goes wrong here.
what is the conclusion?
need serious code optimization?. polyphony mechanism? need to do elegant programming, and maybe adapt to Market new mechanism (i9,Steinberg, Microsoft)?
bespite computers become always more powerful, developpers should keep an eye on performance impact of their products.
and keep in mind that all kind of AUDIO Programs should be expected to run at lowest latencies on Hi-end systems.
i don't have yet perform benchs on CMI V and DX7 but i expect trouble too. like the Matrix12 v.
