evanrabby
09-01-2009, 06:47 AM
i have struggled with DAW (who is that guy anyway?) since 1998 using cubase vst 3.7 or something, i remember getting 16 channels running on a pentium 100 with a few fx... cpu straight out at 100% LOL
i will be loosing my next $900 on i7 components soon, to finally get rid of the low latency disease we all suffer from; but ill introduce my findings relating to everything up to that point for now because it will contribute to understanding:
heres my current understanding on core arbitration/asio headroom:
current system: p5b deluxe, q6600 at 400 fsb@9x = 3.6 ghz, 2 gb dual channel ddr2 (mini ninja keeps it at 60 deg max on air). win xp sp2, tweaked with xSetup.
motu 2408 mkII w/pci-424, all tests running at 128 samples.
i can run this project (these show, set to on, how many reaxcomp i can run):
(right click save or just browse directory at http://companyzero.ca/dawbench/ )
http://companyzero.ca/dawbench/2or4Cpu52or60to72.RPP
either i can max out 2 cpu right up to 100% (52% total average) with no pops. now set affinity to 4 cores it will show max 72% (total average and individual cpu), (with no pops of course, unless you add over 40 more reaxcomp), according to task manager. (set affinity function inside reaper is identical in performance and you can see it just turns the same checkboxes you see in task manager on or off)
4 cores have to work harder per core, for the same load, this is what im measuring. if they were 1 to 1 efficient they would have shown 52% (total average) or so max, though i understand the overhead involved and perhaps 20% inefficiency is pretty good for reaper.
this type of behaviour is consistent across any type of DAW bench test or real world project i can do. multi cores adds overhead so you arent getting 1 to 1 increases, fair enough.
so far this dawbench universal test is doing hard disk streaming only to ONE stereo output, incredibly efficiently on my system, at close to 100% cpu even across 4 cores (80 reaxcomps):
http://companyzero.ca/dawbench/4cpuAt95.RPP
now, the real efficiency issue comes up below:
look at the same benchmark with input monitoring on, named:
http://companyzero.ca/dawbench/2or4Cpu52or60to72InputEnable.RPP
now using all 4 cores, im at 74% max cpu, only 40 reaxcomps, and after that i get increasing crackles, though i get no system GUI lockup/slowdown at all right up to 100%.
IE i could run this project on 2 cpus and get no dropouts even at 100% usage of the 2 cores, with hard disk streaming only, before i hit the r buttons on all 40 channels, but when i hit r button (input streaming enable) i have to run the 2 cores at 80% each or less (40% total average, 24 reaxcomps instead of 40) to eliminate pops, now put on all 4 cores, and its struggling not to drop out at 74% maximum. notice from above i can turn on 80 instead of 40 reaxcomps if i DONT have input monitoring enabled, running the cpus right up to full on 100% with GUI slowing down, rock solid.
see, the big point of efficiency failure happens when i do what i have always had to do to run my live sound and studio since 2001: stream realtime 2 to 24 inputs to to 2 to 8 outputs. without input monitoring, i can get that great 100% cup usage, but with input monitoring, there are obviously spikes that arent being smoothed out, forcing me to greatly reduce cpu usage. i bet these spikes could be averaged out far better in software, with some serious R&D.
also of course during work i am recording and playing back from hard disk though this is high latency (the hard drive read writes) regardless of buffer settings, and has no real efficiency vs dropout problem.
cubase 2 or 3 behaves similarly with 128 sample buffer input monitoring: i can run one core at 95% no dropouts or 4 cores only at 25%, no dropouts but with no rhyme or reason its less stable with multi cores, a pop can crop up occasionally.
at first i was saying... veeeery suspicious, 100% of one core, 25% of 4, its like its faking multi core use...
heres another factor, and im gonna have to dig up my tests for this (it doesent work with multiple instances of reaper, haha, its because it 'knows' its running another instance, (has certain parallel resource habits probably system calls using cpu0 or something...):
i can run 3 instances of DAW, say nuendo on 1 cpu, cubase on another, old nuendo 1.5 on another, and GET 3x THE POWER OF ANY ONE, IE im then running 24 x 3 inputs, to almost overload fx, to 6 outputs on ONE core each instance, cpu usage right to 100%.
a good example is that i can load a reaper project on 3 cores almost as efficiently as 4, in terms of track and plugin count, then i can run nuendo 2 or 3 on the 4th core only, with multi processing checkbox off, and get perfect stability with a huge input monitoring while recording project, running that one core to 95% or greater, and using far more than just 33% of the track and plug count as the reaper instance.
try anything with any DAW using all 4 cores with one instance and i cannot increase the project to 3x as many plugs and IO streams, but i can do it with 3 different instances.
so i have proven scientifically that there is a method of using all 4 cores on full, it just involves having a developer CARE to do some 'unorthodox' programming. why not think outside of the box if it gets you results? because they all would rather assume you will deal with buying the hardware to solve it rather than them spending the money ONCE on their dev time! that is a FACT.
the method would include running 4 separate processes in their own space, per cpu, then uniting the GUI ONLY, ABSOLUTELY ONLY THE MOUSE/control/keyboard IN AND SCREEN OUT data from the 4 processes, in another smaller process.
this is the most essential result of over a decade of experience with every darned hardware architecture update in the chain with IE m audio, motu, gadget labs (LOL), presonus, soundcards.
lastly, except for reaper, there is a universal rule: EVERY DAW UPDATE INCLUDES A DEGRADATION IN THE AUDIO ENGINE/PERFORMANCE!
(tho reaper actually follows the trend too except with one releases' forward jump for multi cores called the 'experimental' thread behaviour after v 2.206).
'frogs breath, ...veeeery suspicious!'
-from a nightmare before christmas
-cheers
i will be loosing my next $900 on i7 components soon, to finally get rid of the low latency disease we all suffer from; but ill introduce my findings relating to everything up to that point for now because it will contribute to understanding:
heres my current understanding on core arbitration/asio headroom:
current system: p5b deluxe, q6600 at 400 fsb@9x = 3.6 ghz, 2 gb dual channel ddr2 (mini ninja keeps it at 60 deg max on air). win xp sp2, tweaked with xSetup.
motu 2408 mkII w/pci-424, all tests running at 128 samples.
i can run this project (these show, set to on, how many reaxcomp i can run):
(right click save or just browse directory at http://companyzero.ca/dawbench/ )
http://companyzero.ca/dawbench/2or4Cpu52or60to72.RPP
either i can max out 2 cpu right up to 100% (52% total average) with no pops. now set affinity to 4 cores it will show max 72% (total average and individual cpu), (with no pops of course, unless you add over 40 more reaxcomp), according to task manager. (set affinity function inside reaper is identical in performance and you can see it just turns the same checkboxes you see in task manager on or off)
4 cores have to work harder per core, for the same load, this is what im measuring. if they were 1 to 1 efficient they would have shown 52% (total average) or so max, though i understand the overhead involved and perhaps 20% inefficiency is pretty good for reaper.
this type of behaviour is consistent across any type of DAW bench test or real world project i can do. multi cores adds overhead so you arent getting 1 to 1 increases, fair enough.
so far this dawbench universal test is doing hard disk streaming only to ONE stereo output, incredibly efficiently on my system, at close to 100% cpu even across 4 cores (80 reaxcomps):
http://companyzero.ca/dawbench/4cpuAt95.RPP
now, the real efficiency issue comes up below:
look at the same benchmark with input monitoring on, named:
http://companyzero.ca/dawbench/2or4Cpu52or60to72InputEnable.RPP
now using all 4 cores, im at 74% max cpu, only 40 reaxcomps, and after that i get increasing crackles, though i get no system GUI lockup/slowdown at all right up to 100%.
IE i could run this project on 2 cpus and get no dropouts even at 100% usage of the 2 cores, with hard disk streaming only, before i hit the r buttons on all 40 channels, but when i hit r button (input streaming enable) i have to run the 2 cores at 80% each or less (40% total average, 24 reaxcomps instead of 40) to eliminate pops, now put on all 4 cores, and its struggling not to drop out at 74% maximum. notice from above i can turn on 80 instead of 40 reaxcomps if i DONT have input monitoring enabled, running the cpus right up to full on 100% with GUI slowing down, rock solid.
see, the big point of efficiency failure happens when i do what i have always had to do to run my live sound and studio since 2001: stream realtime 2 to 24 inputs to to 2 to 8 outputs. without input monitoring, i can get that great 100% cup usage, but with input monitoring, there are obviously spikes that arent being smoothed out, forcing me to greatly reduce cpu usage. i bet these spikes could be averaged out far better in software, with some serious R&D.
also of course during work i am recording and playing back from hard disk though this is high latency (the hard drive read writes) regardless of buffer settings, and has no real efficiency vs dropout problem.
cubase 2 or 3 behaves similarly with 128 sample buffer input monitoring: i can run one core at 95% no dropouts or 4 cores only at 25%, no dropouts but with no rhyme or reason its less stable with multi cores, a pop can crop up occasionally.
at first i was saying... veeeery suspicious, 100% of one core, 25% of 4, its like its faking multi core use...
heres another factor, and im gonna have to dig up my tests for this (it doesent work with multiple instances of reaper, haha, its because it 'knows' its running another instance, (has certain parallel resource habits probably system calls using cpu0 or something...):
i can run 3 instances of DAW, say nuendo on 1 cpu, cubase on another, old nuendo 1.5 on another, and GET 3x THE POWER OF ANY ONE, IE im then running 24 x 3 inputs, to almost overload fx, to 6 outputs on ONE core each instance, cpu usage right to 100%.
a good example is that i can load a reaper project on 3 cores almost as efficiently as 4, in terms of track and plugin count, then i can run nuendo 2 or 3 on the 4th core only, with multi processing checkbox off, and get perfect stability with a huge input monitoring while recording project, running that one core to 95% or greater, and using far more than just 33% of the track and plug count as the reaper instance.
try anything with any DAW using all 4 cores with one instance and i cannot increase the project to 3x as many plugs and IO streams, but i can do it with 3 different instances.
so i have proven scientifically that there is a method of using all 4 cores on full, it just involves having a developer CARE to do some 'unorthodox' programming. why not think outside of the box if it gets you results? because they all would rather assume you will deal with buying the hardware to solve it rather than them spending the money ONCE on their dev time! that is a FACT.
the method would include running 4 separate processes in their own space, per cpu, then uniting the GUI ONLY, ABSOLUTELY ONLY THE MOUSE/control/keyboard IN AND SCREEN OUT data from the 4 processes, in another smaller process.
this is the most essential result of over a decade of experience with every darned hardware architecture update in the chain with IE m audio, motu, gadget labs (LOL), presonus, soundcards.
lastly, except for reaper, there is a universal rule: EVERY DAW UPDATE INCLUDES A DEGRADATION IN THE AUDIO ENGINE/PERFORMANCE!
(tho reaper actually follows the trend too except with one releases' forward jump for multi cores called the 'experimental' thread behaviour after v 2.206).
'frogs breath, ...veeeery suspicious!'
-from a nightmare before christmas
-cheers