... It then seemed quite tempting to try the following: isolate one of many cores of a CPU from Windows entirely, will leaving Windows operate on the remaining cores to accomplish all the rather mundane tasks of updating the screen, fetching (or storing) data from/to Hard disks, receiving new user data from the keyboard or from the mouse, transferring files over networks, etc…
in brief all the tasks that Windows is rather good at, but keeping the audio engine as much away from it as possible.
The way we made it to work is basically to dedicate "the core"; where we wanted the audio mix engine to run to be operated by a true Real-time kernel that take "possession"; of that core and even makes this core essentially invisible to Windows. It was with great amazement that we soon realized this was not only actually possible but that the results, in terms of achievable deterministic latency were even better than what we could achieve until then with our DSP based cards.
With guaranteed response times in the order of a couple of microseconds (compared to tens of milliseconds under Windows) we were able to bring down the total Live-in to Live-out audio processing delay of the entire mix engine (including complex plugins) to under 1.4 ms which is at least a factor of 10 better than what even the best fine-tuned "Native"; systems can achieve.
The best part of it was however to come. By relaxing slightly the latency constraints (to say 5.4 ms, which is still OK for all but the most stringent live mixing situations) we just couldn't believe how much raw power was available from just one single core of those new Core2 Duo or Core2 Quad processors. We kept on adding input strips after input strips, mix busses after mix busses and quickly managed to reach the limit of what our (by then Pyramix V5) software was able to support while the CPU usage was still showing some moderate figure of between 10% and 20% of total available power...