This issue was discussed in a fairly recent thread. I cut and pasted some very useful information into a Word Document so I could re-visit it as needed.
The information comes from member athlon64, so you should be able to search the threads by member to get to the full thread. The date I created the Word Document was March 1, 2018, so that is the approximate date of the thread.
Here is the info:
In the process i found a lot of usefull info and my friend created something that might help many of you with low buffer recording. So keep reading :)
1.
Real CPU usage VS protools CPU usage:
There is allredy a subject related to this problem but as you all know, the protools CPU usage meter isn't the actual CPU usage for your computer. I haven't really realized what are the factors affecting the system usage meter in protools but i have discovered something:
The lower the buffer is, the higher the chance that you will get random CPU usage spikes that are not related to the actual amount of CPU power that you got remaining. Some people would link this with your computers high DPC latencies which would basically mean that sometimes protools wants instantaneous acess to the CPU but it needs to wait milisecond or two because some other process or driver has the priority.
However, my lenovo P50 at first while testing it showed some drivers spike over 1ms but i have sucessfully solved this by disabling GPU clock speed changing and got my computer to have DPC latencies under 200-300 uS while protools is running, still i would have random CPU usage spikes in the System meter.
So i don't think that DPC latencies that are not very low necessarily mean you will have real time audio problems. But i'm not sure. For an example if i'm surfing online and maybe watching 4K video on youtube, the drivers for my NIC controller (ndis.sys) will sometimes (every 10 minutes or so) hit the max execution time of 2-3ms in latency mon. But that never causes audio crackle or any problems at all.
The solution for this problem lies in the windows task manager but i will write about this at the end of the subject.
2.
How to mix with as many plugins as possible but not overload the CPU.
So all of the problems from segment 1 happen mostly when you try reducing the your buffer to a low setting like 64 if you want to track and have live monitoring. However when you are mixing and want as much CPU power as possible we all mostly rise our buffer settings to 1024.
These high settings eliminate most of the random cpu spikes and the protools system usage meter becomes more closely related to the actuall CPU usage in task manager.
Unless you have problematic plugin chains.
So how this works:
If you have a multicore CPU, protools will run all of the plugins in the same signal chain on the same core. If any of the cores gets overloaded for a moment, protools will stop with the "ran out of power message"
This means that you if you have a plugin using 60% on one of your CPU cores. And you have an 8-core CPU (or 4+4 hyperthreaded) you can feel free to run 8 of these plugins in real time on different tracks (in different signal chains). But if you try inserting 2 of those plugins in the same signal chain, no-go, one core gets overloaded, you get a ran out of cpu power error.
The two biggest CPU hogs that i have in my plugins list and use a lot are:
Izotope ozone 8. So if you use this plugin try not to load the entire "ozone 8" instance if you need just the imager or just the EQ. You can load just the imager for an example and it works well while using less CPU power.
However ozone 8 is not that bad if you have a powerfull cpu and are running a 1024 buffer. I can run about 5 or 6 of them in a single signal chain with an i7 6820HQ.
The, by far, worst CPU hog i have encountered is the Abbey roads plate reverb
in a 96/24 session i can't run more then 5-6 of them even when they are distributed well over different signal chains.
So since this reverb plugin sounds amazing. If you want to use it try to put it only on it's own Aux channel and then just send everything you want to it. That way you may not need more then one in realtime.
The conlusion of this segment is: If you are planning on mixing 100 channels with many plugins distributed well over them, you might be better with a higher core count cpu that might not be clocked that high (like an intel xeon for an example).
If you are going to be running the usuall band session with maybe 30 tracks, and some possibly CPU intensive signal chains. You are better of with a higher clocked CPU with less cores. Because rising the clocks speeds directly reduces CPU usage "per core" in protools system usage meter (i tested this).
3. A partial solution
So far we have concluded that if you are running a high buffer you should only have "ran out of CPU power" problems if you actually overload the cpu with a bad signal chain.
However if we go back to the "recording with a buffer od 64" problem. Many users will be unable to record with a buffer this low even with a very powerfull system. By default, on my P50, just setting the buffer to 64 with no tracks and plugins at all, rises CPU usage over 50% with many random spikes.
And no, by default i can't record tracks at a buffer this low for a long time.
The solution is:
After protools starts. You open task manager in windows, find protools in "processes". Expand it, right click it and click "go to details".
After you see the process in the "details" window. You right click it and you will see "set priority" and "set affinity" options.
If you for an example have a 4 core intel i7 with hyperthreading. Windows will see this as an 8-core processor. In core affinity settings for protools, you have to manually disable protools from using 2 out of 8 cores that you have. You can make it use even less cores, it will work. But for me this was the best balance.
After you have done that you go to "set priority" and set that to "high".
You have now basically given protools 6 out of 8 cores just for itself and no other software or drivers on your PC will interfere with it because they have the remaining two cores for themselves.
For me, after i do this, the CPU usage in the system meter skyrockets down to 1-2% and i can literally record 200 tracks with a 64 buffer and have live monitoring with no problems at all.
I can even do this while running 10-15 basic plugins (eq's compressors and gates"). I tried this out the last week when i was tracking guitars and bass for a band after i tracked drums. So the guitarist had mixed drums, with plugins, going into his headphones, together with his guitar, all going trough protools with a buffer of 64.
4. The script to make this fast
So since this little optimization helped me a lot i made my friend help me make a powershell script that will make this automatic for all of us. The trick is, this doesn't work if you have any kind of program or shortcut that will set Protools CPU affinity and priority when protools is starting. This won't work. Protools first has to start fully, then you have to change these settings.
So this script works really simply. You start protools, after it started, you just doubleclick the script. You can keep it anywhere you want. On the desktop for an example. It sets both the priority and affinity settings automaticaly. I think you need to run it as administrator so you can set it to be ran as administrator automaticaly to make things simple.
There is just one thing that you need to take care about. If you have an 8-core processor the script will work for you right away. 8 core xeon, 4 core i7 with hyperthreading. You are good. If you have a processor with a different number of cores you will have to change one number in the script. The instructions for this are in the script. You just open it with notepad and you will see everything. It's really simple.
Here is the script. I'm peronally running protools 12.5.1 but it should work for other versions.
https://drive.google.com/open?id=16g...if5GAt6WvQhaRP
Please write about how this has helped you.
________________________________________
Last edited by athlon64; Today at 06:50 AM.