By default, Mixbus requires significantly more CPU resources than a typical DAW, because it is emulating the operation of an analog console.
Nevertheless, an older 2GHz CPU should be able to handle dozens of tracks and several plugins, with reasonable settings. Note that, because of the way Mixbus works, it does not increase the cpu to enable all the EQs and compressors; the DSP load for that processing is already pre-allocated when you run Mixbus. This means that if Mixbus is running smoothly, you won't accidentally overload your system if you enable all the channelstrip features while you are mixing.
A modern i7-class processor has the capability to run 100s of tracks and lots of plugins in Mixbus. HOWEVER: even the most powerful cpu can have very poor realtime audio performance if it is not adequately "woken up" at regular intervals to service the incoming audio buffers from the soundcard.
Firstly, you need to understand that the CPU meter on your computer averages the cpu usage over a very long period (perhaps one second). This gives a general indication of how busy your CPU is. This is a useful number to know if we are trying to finish a hard math problem, or if we are measuring battery usage.
But in digital audio, the timing is much more sensitive. When the soundcard passes us a buffer, Mixbus has to be alerted by your OS, process the audio buffer, and return it to the soundcard before the soundcard needs to play it out. If we don't wake up in time, or we don't get finished in time, then you hear a "click" caused by the lack of audio (we call these xruns, short for over-run or under-run).
In the case of a 1024 buffer size, this has to be done within (1024/44100) 25ms, or about 1/40th of a second. Reduce the buffersize to 64, and the computer has to wake up every 1.5 milliseconds.... 650 times every second... absolutely reliably ... or you'll hear a click.
This is complicated by the fact that it's the OS's job to "wake us up" and tell us that the soundcard has some data for us. Some OS's and drivers are better at this than others. Let's say that the computer always responds within 1ms that the soundcard is ready. In our 1024 example, this leaves us a heathy 24ms to work our DSP magic. But in the 64-sample buffersize, we only have 0.5ms left to work. 2/3rds of the time was already wasted before Mixbus even had a chance to operate!
Our DSP meter takes this timing into account. If we have a 20ms buffer size, and it takes us 10ms to process the audio, then we are finished within 50% of the allotted time and that's what we display in the meter. This is a very accurate indication of your computer's ability to process audio.
This explains why the selected buffersize is so critical to the DSP load. A 256-sample buffersize is about 6ms, so if your computer sometimes waits 5ms after receiving the soundcard interrupt before it "wakes us up", we only have 1ms remaining to do our work. There's plenty of CPU power to get the work done if we are woken-up in time; but if the OS is slow to wake us up, then the desktop CPU usage can look very low, but you are still encountering glitches.
Yet another complication is the fact that sometimes the computer can be interrupted ... perhaps by an incoming email; a bit of scheduled disk cleanup; or a screensaver suddenly kicking in. Or it could be something entirely internal to the computer motherboard: perhaps the video-card occasionally hogs the internal bus and doesn't let the soundcard alert the motherboard that it has a buffer. These problems can be very hard to troubleshoot.
How bad is a "click", really? If you are mixing by yourself in your home studio, perhaps you don't care if the system clicks once or twice an hour. The clicks won't be heard in the final export. But in a high-profile recording session, you wouldn't want even a single click to occur, and get captured in your recording. And that's a lot to ask of a general-purpose computer, because they weren't built for that kind of real-time consistency.
If you have time to watch this (very good, but very long) video, you can learn more details: https://www.youtube.com/watch?v=GUsLLEkswzE
OK, so what can we do about it?
The quick & easy methods to minimize the DSP load are: increase the "buffer size" in the Audio Setup dialog; use a lower sample rate, reduce the number of tracks, or reduce the number of plugins in your session. And of course using a faster computer, with more CPU cores, is desirable. These methods might require that you compromise your settings, based on the task at hand: when you need reliable low-latency, you should use as few tracks and plugins as practical. And when you are mixing, you should increase the buffersize (latency) so you can reliably access more tracks and plugins.
If you are using a USB device, make sure it is connected directly to the computer and not to a USB "hub". We've had lots of users report that they had problems with cpu usage, only to learn that the device was not directly connected to the computer. Furthermore, the realtime performance of USB connections can vary widely, depending on which "bus" is used internally, on the motherboard. You might find that one USB port works remarkably better than the others. Sometimes you can infer this behavior by looking at the motherboard specifications: you want a usb port that is most directly connected to the CPU interrupts, and definitely not one that is connected to an internal hub.
If you are using a cheap windows computer, or a build-your-own computer, there's no way to guess the interaction between the various hardware interrupts (usb devices, video cards, etc etc). You won't know if your system is realtime stable until you build it and test it. This is why optimized systems (like pro-level macs and custom built audio PCs) can have much better performance. The developers have tested several combinations until they found devices that don't interrupt each other. In other words "You get what you pay for".
I'm often asked whether more memory will improve the DSP%. More memory should have no effect on the DSP usage, unless your system is starved for memory and is heavily relying on disk caching. If that's the case, then it's probably easier to close some apps while you are recording, rather than purchase more memory.
If you Google-search for "computer audio performance", you will find lots of resources online. Here are some of the best links we've found. Note that this information is provided "at your own risk":
Mac performance optimizations:
Macs usually "just work" for realtime audio, and this is why they are popular among media producers. (about 50% of DAW users are on mac, even though mac only accounts for 10% of total computer users)
If your mac doesn't have good realtime performance, there's generally not much you can do about it (except buy another mac). But here are some tips that might help:
Windows performance optimizations:
Windows systems can also perform very well. But there is a bewildering number of factors that can affect Windows performance, and it can be very hard to determine what steps (if any) will improve your system. Here are some online resources that can help you optimize your Windows system performance:
- https://support.focusrite.com/hc/en-gb/articles/207355205-Optimising-your-PC-for-Audio-on-Windows-10
- https://support.native-instruments.com/hc/en-us/articles/209571729-Windows-Tuning-Tips-for-Audio-Processing
- https://www.audinate.com/faq/how-can-i-tune-windows-pc-best-audio-performance
- http://www.sweetwater.com/sweetcare/articles/pc-optimization-guide-for-windows-7/
Even more technical details (windows-centric, but sort-of applicable to Intel-based mac and linux, too):