the average cpu load won't tell you a lot, since the cpu speed is usually not constant, but may be modulated (adding some latency hotspots). in general, i'd recommend to disable frequency scaling, turbo mode (for nehalem cpus) and smt, since it may confuse numbers and can increase the thread wakeup latency significantly, if you want to use a machine for low-latency real-time audio applications.
thanks for the tip. I have no idea how to do that though. I admit not having searched for very long (it's late), but i couldn't find an easy peasy how-to disable frequency scaling, or about that turbo mode and smt stuff... maybe you (or someone else) can explain this in a bit more detail?
usually these are bios options. the basic idea for disabling this stuff is to avoid system-level interrupts, that could introduce considerable wakeup latencies in the worst case.
so, still plenty of overhead on the 4th core, but it doesn't seem to be used.
from my understanding, you should split your path into 4 pieces of equal load, using 3 pd~ objects, if you want to optimize it for a quad-core cpu.
hmm, if I try to load one patch into a pd~ object I get garbled sound, even without switch~ing it on. Would you think if I split off more of my main patch into more pd~ objects it would improve ? The fact that using pd~ results in more hickups than a normal abstraction leads me to suspect something else is wrong...
if your patch works fine on a single cpu, but not with pd~, i would also suspect, that something else is going wrong. there could be various reasons for the hickups like scheduling issues, buffer synchronization issues and the like. however, i have no insight in the implementation of pd~, but since pd~ is part of vanilla pd, i am sure, miller will be interested in resolving all issues, that pd~ may have.
cheers, tim