The No.1 Website for Pro Audio
 All  This Thread  Reviews  Gear Database  Gear for sale     Latest  Trending
Protools 12.XX performance optimization script and important tips!
Old 1st March 2018
  #1
Here for the gear
 

Protools 12.XX performance optimization script and important tips!

Hello.

So after buying a new lenovo P50 i started doing the classical list of windows optimizations to make it run as good as possible.
However, no matter what i did i found some weird behavoiur considering the Protools System Usage meters. It's the usuall type of problem. Cpu usage gets random spikes, not directly linked to actuall CPU usage in task manager and protools then sometimes stops with the "ran out of cpu power" message.

Of course, lower buffer sizes and more Cpu hogging plugins you have, the more often that problem happens.
So, since IT is also my profession. I decided to try tracking these problems deeper since they look to me like bad optimization.

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.

ProToolsFix.bat - Google Drive

My personal configuration:
Intel i7 6820HQ, RAM:32GB DDR4. SSD: Samsung Nvme. GPU: Nvidia quadro M2000M
Audio interface: Focusrite 2i4 1st. gen

Please write about how this has helped you.
Old 1st March 2018
  #2
Lives for gear
 

Not to miss the point of your post, but I’m struggling to imagine the average scenario where one would require 6 instances of a plate Reverb and or Ozone in a single session....
Old 1st March 2018
  #3
Here for the gear
 

Quote:
Originally Posted by kslight View Post
Not to miss the point of your post, but I’m struggling to imagine the average scenario where one would require 6 instances of a plate Reverb and or Ozone in a single session....

You are right. But it's good to know what might be hogging the cpu if you are having problems at a 1024 buffer.
I also doubt someone will load 6 ozones or abbey reverbs in a session. But for an example, you might have a nasty signal chain with a few eq's, compressors, an ozone, and then you might want to load the abbey plate on it an you will get an error because that core got overloaded. So it's good to know who the cpu hogs are and how it all works together.
Old 1st March 2018
  #4
Lives for gear
 

Quote:
Originally Posted by athlon64 View Post
You are right. But it's good to know what might be hogging the cpu if you are having problems at a 1024 buffer.
I also doubt someone will load 6 ozones or abbey reverbs in a session. But for an example, you might have a nasty signal chain with a few eq's, compressors, an ozone, and then you might want to load the abbey plate on it an you will get an error because that core got overloaded. So it's good to know who the cpu hogs are and how it all works together.
I know what you mean. Though the normal practice of using the Reverb on an aux send would normally put it on a different core, correct?


I’ve noticed that having multiple instances of Two Notes WoS (and nothing else) can cause strangeness. Even on a 12 core Mac Pro where hopefully available cores is not an issue.
Old 1st March 2018
  #5
Here for the gear
 

Quote:
Originally Posted by kslight View Post
I know what you mean. Though the normal practice of using the Reverb on an aux send would normally put it on a different core, correct?


I’ve noticed that having multiple instances of Two Notes WoS (and nothing else) can cause strangeness. Even on a 12 core Mac Pro where hopefully available cores is not an issue.

True.
So for an example. This is directly from a test that i did while watching core usage.
I load an abbey roads plate on it's own aux track. One core jumps to around 30% load. I try adding more of them. The maximum i can run on a single aux mixbus is around 4, and even with 4 it stops sometimes. With 5 of them on the same aux, one core goes to 100% right away and i can't play tracks at all.

However if i keep the number of abbey roads plates on a single aux mixbus under 4. And then duplicate that mixbus with 3 abbey road plates. I can run about 15 abbey roads plate reverbs in the session with no errors. However. In this unrealistic situation, all of my 8 cores are running at around 80%. And it's not that just the protools cpu usage meter is telling me 80% per core. Task manager says the exactly same thing. With this example, you are actually running out of physical CPU power and you need a better CPU if you want to run more.

This is however not a realistic situation. What might happen during mixing is usually overloading one core with a few CPU hogging plugins on the same channel. This seems to be simply code not good enough. Protools should know how to use resources more balanced considering that when i use an AUX mixbus for a reverb, then send a channel to it. I'm basicaly getting the same result as just inserting it directly onto the channel. But the mixbus solution usually gives you a better balanced CPU usage scenario.
Old 11th March 2018
  #6
Here for the gear
 

Thank you, thank you, thank you!

In our studio we have a brand new custom built PC that has hardly been able to run Pro Tools without error since we got it. This is a screaming Beast of a machine: Asus x299 Prime-A motherboard, Samsung EVO 850 SSD boot Drive, 64 gb of DDR4 RAM, an additional 1tb drive for audio and samples, Focusrite RedNet PCIeR card to interface with our RedNet gear, and a Universal Audio Apollo 8p. We could most of the time record okay at 2048 sample buffer size, but many times we would get random clicks and pops. Forget about recording at 64 samples. We also couldn't mix a 32 Channel session with more than a couple of plugins before the system usage meters went crazy, and stall the session out. We were resorting to mixing on our 2011Mac since it was stable.

As soon as I ran this file, tweaked for our 20 core system, I was able to run our sessions, and I don't have to worry about how many plugins are running anymore. I haven't tried recording at low buffer yet, but it looked pretty promising when I record enabled a few channels at 64 samples.

Is Pro Tools really written so badly for Windows that somebody has to come up with a hack like this just to make it work? I just don't understand why they can't put more R&D into it so that it just works. Not everybody has the kind of cash to step up to a Pro Tools HD or HDX rig. Again thanks to the OP for this fix, and the knowledge that you have shared!
Old 12th March 2018
  #7
Here for the gear
 

Quote:
Originally Posted by botw View Post
Thank you, thank you, thank you!

In our studio we have a brand new custom built PC that has hardly been able to run Pro Tools without error since we got it. This is a screaming Beast of a machine: Asus x299 Prime-A motherboard, Samsung EVO 850 SSD boot Drive, 64 gb of DDR4 RAM, an additional 1tb drive for audio and samples, Focusrite RedNet PCIeR card to interface with our RedNet gear, and a Universal Audio Apollo 8p. We could most of the time record okay at 2048 sample buffer size, but many times we would get random clicks and pops. Forget about recording at 64 samples. We also couldn't mix a 32 Channel session with more than a couple of plugins before the system usage meters went crazy, and stall the session out. We were resorting to mixing on our 2011Mac since it was stable.

As soon as I ran this file, tweaked for our 20 core system, I was able to run our sessions, and I don't have to worry about how many plugins are running anymore. I haven't tried recording at low buffer yet, but it looked pretty promising when I record enabled a few channels at 64 samples.

Is Pro Tools really written so badly for Windows that somebody has to come up with a hack like this just to make it work? I just don't understand why they can't put more R&D into it so that it just works. Not everybody has the kind of cash to step up to a Pro Tools HD or HDX rig. Again thanks to the OP for this fix, and the knowledge that you have shared!

Yeah i don't understand it either. If a small tweak like this can improve performance by so much in some situations why isn't it coded into protools itself.

Just out of curiosity. Have you checked the DPC latencies of your PC with latencymon? What are the peaks when computer is under load?
Old 12th March 2018
  #8
TNM
Lives for gear
Quote:
Originally Posted by botw View Post
Thank you, thank you, thank you!

In our studio we have a brand new custom built PC that has hardly been able to run Pro Tools without error since we got it. This is a screaming Beast of a machine: Asus x299 Prime-A motherboard, Samsung EVO 850 SSD boot Drive, 64 gb of DDR4 RAM, an additional 1tb drive for audio and samples, Focusrite RedNet PCIeR card to interface with our RedNet gear, and a Universal Audio Apollo 8p. We could most of the time record okay at 2048 sample buffer size, but many times we would get random clicks and pops. Forget about recording at 64 samples. We also couldn't mix a 32 Channel session with more than a couple of plugins before the system usage meters went crazy, and stall the session out. We were resorting to mixing on our 2011Mac since it was stable.

As soon as I ran this file, tweaked for our 20 core system, I was able to run our sessions, and I don't have to worry about how many plugins are running anymore. I haven't tried recording at low buffer yet, but it looked pretty promising when I record enabled a few channels at 64 samples.

Is Pro Tools really written so badly for Windows that somebody has to come up with a hack like this just to make it work? I just don't understand why they can't put more R&D into it so that it just works. Not everybody has the kind of cash to step up to a Pro Tools HD or HDX rig. Again thanks to the OP for this fix, and the knowledge that you have shared!
20 cores would mean 40 logical which is way over windows 10 of 32 limit per app..(in reality 28 as windows reserves 4) - that could be the cause of your spikes before optimisation..

As far as the OP.. I am glad there are ways to improve performance on windows and I am still so confused whether to get a windows computer or stay on mac and get an imac pro.

Unfortunately, nothing seems to be able to get the mac under control if trying to record at under 128 buffer with live monitored effects and/or VI's.

There's no way that I know of to disable certain cores just for PT.. in mac if you use xcode to disable cores it disables them system wide.

I have talked to many mac users with this issue with PT.. whereas on the very same computer and audio interface i can play VI's in cubase and Logic at 32 samples.. In Logic i can monitor arm 32 audio tracks each with a fab filter Pro R, 32 instances, at 32 buffer, and logic flawlessly spreads the load among all 8 logical cores..
at 32 buffer I can only arm and record 32 audio tracks in PT but with NO effects anywhere.

This is why the only solution for good performance with PT on a mac and still having reasonable monitoring without any pro tools spikes, is to use an apollo and set pro tools to 128 buffer which is fine for VI's anyway (apollo 128 buffer output latency is 3.5ms which is fine for VI's), and monitor through apollo.
or go HDX..
HDN seems to have the issues as well on macs at least.

Something goes haywire with PT.. there is something wrong and avid need to fix it, a disproportionate psychotic cpu spike usage at anything under 128 buffer..

I'm going to try the above fix on my 2.3ghz i7 windows 7 laptop and if it works, i'll look at windows more seriously, however I am very concerned about the windows plugin instance limitation which heavily affects UAD users. So it's really tough for me to decide.
Old 12th March 2018
  #9
Lives for gear
 
TREMORS's Avatar
Isn't there still a #of CPUs/cores setting in Pro Tools itself?

I'm on 10 still.

What is it set to relative to windows' affinity?
Old 13th March 2018
  #10
Here for the gear
 

When I said 20 cores, I was including the hyper-threaded cores. The i9 processor we have is a 10 core processor so with hyperthreading we have 20 accessible in Windows. My bad.

As a UAD user, doesn't your Apollo take the processing of those UAD plugins off of the system? Even though they are used in Pro Tools, the processors in the Apollo, or any of the UAD accelerator units are supposed to do the processing on those plugins. That's one of their selling points, right?

Anyway, my guys mixed a session today with heavy Waves plugin usage after running the script, and they said the system hardly broke a sweat! I am so ecstatic right now. I honestly can't wait to try some low latency recording too.

Quote:
Originally Posted by TNM View Post
20 cores would mean 40 logical which is way over windows 10 of 32 limit per app..(in reality 28 as windows reserves 4) - that could be the cause of your spikes before optimisation..

As far as the OP.. I am glad there are ways to improve performance on windows and I am still so confused whether to get a windows computer or stay on mac and get an imac pro.

Unfortunately, nothing seems to be able to get the mac under control if trying to record at under 128 buffer with live monitored effects and/or VI's.

There's no way that I know of to disable certain cores just for PT.. in mac if you use xcode to disable cores it disables them system wide.

I have talked to many mac users with this issue with PT.. whereas on the very same computer and audio interface i can play VI's in cubase and Logic at 32 samples.. In Logic i can monitor arm 32 audio tracks each with a fab filter Pro R, 32 instances, at 32 buffer, and logic flawlessly spreads the load among all 8 logical cores..
at 32 buffer I can only arm and record 32 audio tracks in PT but with NO effects anywhere.

This is why the only solution for good performance with PT on a mac and still having reasonable monitoring without any pro tools spikes, is to use an apollo and set pro tools to 128 buffer which is fine for VI's anyway (apollo 128 buffer output latency is 3.5ms which is fine for VI's), and monitor through apollo.
or go HDX..
HDN seems to have the issues as well on macs at least.

Something goes haywire with PT.. there is something wrong and avid need to fix it, a disproportionate psychotic cpu spike usage at anything under 128 buffer..

I'm going to try the above fix on my 2.3ghz i7 windows 7 laptop and if it works, i'll look at windows more seriously, however I am very concerned about the windows plugin instance limitation which heavily affects UAD users. So it's really tough for me to decide.
Old 13th March 2018
  #11
TNM
Lives for gear
Quote:
Originally Posted by botw View Post
When I said 20 cores, I was including the hyper-threaded cores. The i9 processor we have is a 10 core processor so with hyperthreading we have 20 accessible in Windows. My bad.

As a UAD user, doesn't your Apollo take the processing of those UAD plugins off of the system? Even though they are used in Pro Tools, the processors in the Apollo, or any of the UAD accelerator units are supposed to do the processing on those plugins. That's one of their selling points, right?

Anyway, my guys mixed a session today with heavy Waves plugin usage after running the script, and they said the system hardly broke a sweat! I am so ecstatic right now. I honestly can't wait to try some low latency recording too.
of course, that's what I am saying with the apollo.. it's the only way i can monitor through effects at reasonable latency, and there is no cpu hit...

If i were monitoring through pro tools itself, through core audio and native aax effects, it would be a nightmare at 64 buffer let alone impossible at 32, as i like to monitor a;; 32 live inputs at one time (70 with my 2 analog desks included).

128 is the only usable buffer for me and that is far too high for monitoring, hence, the apollo solution.
Old 13th March 2018
  #12
Lives for gear
 

Quote:
Originally Posted by TREMORS View Post
Isn't there still a #of CPUs/cores setting in Pro Tools itself?

I'm on 10 still.

What is it set to relative to windows' affinity?
Not on current versions.
Old 19th March 2018
  #13
Lives for gear
 
T_R_S's Avatar
6 Abbey Road reverbs in one session - the solution is simple use 'Freeze'
Or simple use a reverb bus and don't use a single reverb plug on every single track
I downsized from 3 UAD OCTO's to one when freeze came out. So now any problematic CPU hog plugins are no longer a problem.
Old 19th March 2018
  #14
Gear Nut
 
cdruzeta's Avatar
Thank you.
One of the best posts I've ever seen.
Old 19th March 2018
  #15
Lives for gear
 
jimmyboy7's Avatar
Same for a dual Xeon? Any change necessary?
Old 20th March 2018
  #16
Here for the gear
 

So if I did this correctly I should not see any System Usage CPU activity in reserved cores? Just checking due to mental block involving binary.
I have a 6 core + 6 virtual i7 and the usage display is sideways pyramid like with equal usage up in both 1,2 and 11,12. I converted binary 111111111100 to decimal 4092 and entered per above. I added 16 instances of waves Abbey Road Plates to an existing session (128 samples)
Old 20th March 2018
  #17
Here for the gear
 

Quote:
Originally Posted by joeycola View Post
So if I did this correctly I should not see any System Usage CPU activity in reserved cores? Just checking due to mental block involving binary.
I have a 6 core + 6 virtual i7 and the usage display is sideways pyramid like with equal usage up in both 1,2 and 11,12. I converted binary 111111111100 to decimal 4092 and entered per above. I added 16 instances of waves Abbey Road Plates to an existing session (128 samples)
If you did it correctly. The cores that you disabled for protools should be used only by the remaining windows processes. So if you are loading the cpu heavily with protools, but there is not much running in the background. The remaining cores that Protools doesn't have affinity on, should stay quiet unloaded.

You can check the affinity manually in the task manager. That way you can check if you modified the script correctly to work for you.
Old 20th March 2018
  #18
Lives for gear
 
JonMiller's Avatar
Quote:
Originally Posted by TNM View Post
of course, that's what I am saying with the apollo.. it's the only way i can monitor through effects at reasonable latency, and there is no cpu hit...

If i were monitoring through pro tools itself, through core audio and native aax effects, it would be a nightmare at 64 buffer let alone impossible at 32, as i like to monitor a;; 32 live inputs at one time (70 with my 2 analog desks included).

128 is the only usable buffer for me and that is far too high for monitoring, hence, the apollo solution.
I run 3 Windows based rigs this way and never have a problem with buffer or IO. I run i7 and Windows 7 64 bit on all of them, 32GB of ram, SSD for windows drive, 10k data drive, 10k VI drive, Pro-tools 11, no issues.

The only time I ever had the problems you are having is when I had the UAD software installed on one rig, I have since ditched UAD. The IO drivers are garbage on Windows.
Old 22nd March 2018
  #19
TNM
Lives for gear
Quote:
Originally Posted by JonMiller View Post
I run 3 Windows based rigs this way and never have a problem with buffer or IO. I run i7 and Windows 7 64 bit on all of them, 32GB of ram, SSD for windows drive, 10k data drive, 10k VI drive, Pro-tools 11, no issues.

The only time I ever had the problems you are having is when I had the UAD software installed on one rig, I have since ditched UAD. The IO drivers are garbage on Windows.
we are talking about pro tools 12 and 2018.

Something changed that avid ruined in low buffer sizes.

Regardless, exactly how many tracks do you monitor at 32 or 64 buffer at one time, and how many third party effects when you do that?

I use thunderbolt apollos.. their drivers are top notch. Only the USB3 and firewire ones were not. Even on windows, TAFKAT has confirmed UAD apollo thunderbolt is one of the BEST performing interfaces, period.
Old 22nd March 2018
  #20
Lives for gear
 
JonMiller's Avatar
Quote:
Originally Posted by TNM View Post
we are talking about pro tools 12 and 2018.

Something changed that avid ruined in low buffer sizes.

Regardless, exactly how many tracks do you monitor at 32 or 64 buffer at one time, and how many third party effects when you do that?

I use thunderbolt apollos.. their drivers are top notch. Only the USB3 and firewire ones were not. Even on windows, TAFKAT has confirmed UAD apollo thunderbolt is one of the BEST performing interfaces, period.
At a rough guess, 80 tracks, 15-20 busses, 2-3 plug-ins per track. Plugins are normally, slate tape, slate mix rack, fab filter eq. Busses normally contain buss compressor, slates reverb and various sound toys plugins.
Old 22nd March 2018
  #21
TNM
Lives for gear
Quote:
Originally Posted by JonMiller View Post
At a rough guess, 80 tracks, 15-20 busses, 2-3 plug-ins per track. Plugins are normally, slate tape, slate mix rack, fab filter eq. Busses normally contain buss compressor, slates reverb and various sound toys plugins.
i'd LOVE to see a video of your machine with 80 tracks armed for record at 32 buffer and those effects..

I will pay your normal rate for you to do that.. i need to see the cpu meter of pro tools to understand if it is performing differently on windows to mac.

I guess it's about 15 minutes work tops, only 5 minutes needed in PT.. so a quarter of an hour's in $$$?

No one has ever shown me such a thing and this is exactly what I need to see, cause no one on mac can do such a thing in pro tools...

so if windows is that much better.... then.. but please understand i need to see it with my own eyes
Old 23rd March 2018
  #22
Here for the gear
 

Quote:
Originally Posted by TNM View Post
i'd LOVE to see a video of your machine with 80 tracks armed for record at 32 buffer and those effects..

I will pay your normal rate for you to do that.. i need to see the cpu meter of pro tools to understand if it is performing differently on windows to mac.

I guess it's about 15 minutes work tops, only 5 minutes needed in PT.. so a quarter of an hour's in $$$?

No one has ever shown me such a thing and this is exactly what I need to see, cause no one on mac can do such a thing in pro tools...

so if windows is that much better.... then.. but please understand i need to see it with my own eyes
Yes, what he is talking about sounds quiet amazing for any machine.
I mean i'm happy with my lenovo P50 performance. But i could never go buffer 32 with any significant amount of plugins.
I can however run plenty of plugins that are not CPU hogs on a buffer of 64. Fab filter eq's gates and compressors for an example. But if i leave an abbey roads plate on at a 64 buffer it's going to be on the limit and sometimes start crackling.

Overall, with a well build windows machine that is set-up right. I'm sure you can get more performance then with a modern mac. The problem is, you need to know your way around windows problems.
Most people in this industry come from music and want a plug and play solution.

I came from IT world, with passion for the techincal side of mixing and music.
So for a user like me an apple computer is a big no-go. It would give me a much worse overall user experience.

It seems to me that many people from the apple side would understand this if they let someone knowledgable set them up a windows PC the right way. And if they stopped buying apple equipment just because every big studio in the world uses it... It's just a piece of equipment. Nothing except "how it serves you" should be a factor.
Old 23rd March 2018
  #23
Lives for gear
 
JonMiller's Avatar
To be accurate, I don't think I noticed 80 tracks armed for record in the thread. That said, I think I could mock up a session in the next few days and give it a try to see what happens.
Old 25th March 2018
  #24
TNM
Lives for gear
Quote:
Originally Posted by JonMiller View Post
To be accurate, I don't think I noticed 80 tracks armed for record in the thread. That said, I think I could mock up a session in the next few days and give it a try to see what happens.
you misunderstood then.. I said monitored tracks at low buffer.. thought that implied it..

My apologies if my explanation OTOH was not clear enough.


My issue with PT is working at 32 or 64 buffer with ARMED tracks.. i can set the buffer at 32 also even on my macbook and run huge projects.. but if i wanted to record to 64 tracks simultaneously.. no way.. not with a reverb monitor or anything like that.. PT's own factory plugins are fine at any buffer.

My windows 7 machine behaves the same as my mac with PT.. as soon as you go under 128 performance gets WAY worse.. by a multiplier that is not consistent with any other DAW..

I can record vi's in cubase at 32 all day.. in fact, at 32 buffer, I am able to record arm 32 stereo audio tracks and manage to get a fab filter pro R on 16 of them before dropouts. On cubase. Logic is close second.

I can't get ONE pro R at 32 buffer if i am monitoring 32 tracks in PT.. i can get one or two at 64 buffer.. 128 suddenly equals all the other DAWs.

I am far from the only one having experienced this.. even the guy i trust for pro DAW builds told me similar (but his tests were with armed VI's).

Many posts at pro tools forum about it. A lot of problems are solved simply going to 128 buffer.

Of course a top windows machine with turbo disabled and all power saving disabled (latter can not be done on mac), say an 8700K set to a permanent 4.5ghz, will run rings around say something like the 2013 mac pro. But it's still relative and pro tools AFAIK still reacts in a way that no other DAW does at low buffer sizes.

This is why i was genuine in the offer of paying you for the video, cause i'd then ask you exactly what your system was and i'd look at one myself.

Regardless it probably doesn't matter as i've spent the last month learning Cubase, and besides the ****ty way it handles clip volume in comparison to PT, i think i am ready to make it my forever DAW. Performance is fantastic and i can keep buying Apollos and add them to the input i/o as there is no 32 limit like Pro tools.

I'll be very curious to see what you end up finding out anyway re performance.

Cheers
Old 25th March 2018
  #25
Here for the gear
 

TNM:

Your problem is very confusing to me. Because in my research. After i did the optimizations that i wrote the entire subject about (affinity and priority thing)
It doesn't make much difference weather i'm recording 20 or 50 tracks at a 64 buffer. Plugins are the problem. Not recording.
At that kind of a buffer you run out of CPU power quiet fast. I still can give the guitarist for an example, 10 channels of drums with gates, eq's and compressors on each channel (fab filters) but at a buffer that low reverbs would be problematic... anything very cpu demanding would be problematic.
Not arming the tracks. That's completly fine with CPU load. But only if i do the affinity optimization. If i don't the cpu usage goes trough the roof as soon as i touch "record enable" on some tracks with a buffer of 64.
Old 25th March 2018
  #26
TNM
Lives for gear
Quote:
Originally Posted by athlon64 View Post
TNM:

Your problem is very confusing to me. Because in my research. After i did the optimizations that i wrote the entire subject about (affinity and priority thing)
It doesn't make much difference weather i'm recording 20 or 50 tracks at a 64 buffer. Plugins are the problem. Not recording.
At that kind of a buffer you run out of CPU power quiet fast. I still can give the guitarist for an example, 10 channels of drums with gates, eq's and compressors on each channel (fab filters) but at a buffer that low reverbs would be problematic... anything very cpu demanding would be problematic.
Not arming the tracks. That's completly fine with CPU load. But only if i do the affinity optimization. If i don't the cpu usage goes trough the roof as soon as i touch "record enable" on some tracks with a buffer of 64.
there's nothing confusing then.. your experiences are the same as mine. If you need to use a reverb at low buffer for monitor, dverb is the only one that doesn't cause problems.

But what I am saying is, that this is a pro tools problem.

In reaper( i hate using it but just did it for the test), cubase and logic, on the very same mac i have issues with Pro tools, I can set the buffer to *32*, yes, *32*, and put 16 reverbs monitoring at 32 buffer, with 32 stereo tracks (or 64 mono) armed, ready to record. This is not possible in Pro tools.

Of course no one monitors with 16 reverbs, but the point is, it can do it, which shows the huge performance discrepancy between pro tools and other DAW..

Makes sense now?

Cheers
Old 25th March 2018
  #27
Lives for gear
 
JonMiller's Avatar
Quote:
Originally Posted by TNM View Post
you misunderstood then.. I said monitored tracks at low buffer.. thought that implied it..

My apologies if my explanation OTOH was not clear enough.


My issue with PT is working at 32 or 64 buffer with ARMED tracks.. i can set the buffer at 32 also even on my macbook and run huge projects.. but if i wanted to record to 64 tracks simultaneously.. no way.. not with a reverb monitor or anything like that.. PT's own factory plugins are fine at any buffer.

My windows 7 machine behaves the same as my mac with PT.. as soon as you go under 128 performance gets WAY worse.. by a multiplier that is not consistent with any other DAW..

I can record vi's in cubase at 32 all day.. in fact, at 32 buffer, I am able to record arm 32 stereo audio tracks and manage to get a fab filter pro R on 16 of them before dropouts. On cubase. Logic is close second.

I can't get ONE pro R at 32 buffer if i am monitoring 32 tracks in PT.. i can get one or two at 64 buffer.. 128 suddenly equals all the other DAWs.

I am far from the only one having experienced this.. even the guy i trust for pro DAW builds told me similar (but his tests were with armed VI's).

Many posts at pro tools forum about it. A lot of problems are solved simply going to 128 buffer.

Of course a top windows machine with turbo disabled and all power saving disabled (latter can not be done on mac), say an 8700K set to a permanent 4.5ghz, will run rings around say something like the 2013 mac pro. But it's still relative and pro tools AFAIK still reacts in a way that no other DAW does at low buffer sizes.

This is why i was genuine in the offer of paying you for the video, cause i'd then ask you exactly what your system was and i'd look at one myself.

Regardless it probably doesn't matter as i've spent the last month learning Cubase, and besides the ****ty way it handles clip volume in comparison to PT, i think i am ready to make it my forever DAW. Performance is fantastic and i can keep buying Apollos and add them to the input i/o as there is no 32 limit like Pro tools.

I'll be very curious to see what you end up finding out anyway re performance.

Cheers
I have a continuous non-edited single shot video of 2 plugins across 72 tracks all recording at the same time at a buffer of 64. I show the startup of the computer recording to an external USB drive. The video is 6 minutes or so.

The video is inside this folder on my google drive.

Pro tools - Google Drive
Old 25th March 2018
  #28
Lives for gear
 
JonMiller's Avatar
I should also add, this video is on my home edit rig in my home office.
Old 25th March 2018
  #29
TNM
Lives for gear
Quote:
Originally Posted by JonMiller View Post
I should also add, this video is on my home edit rig in my home office.
will check it out ASAP then copy the test on my mac and see how far I get in comparison.

What CPU may i ask>

Oh, and thank you VERY MUCH! I owe you one.
Old 25th March 2018
  #30
Lives for gear
 
JonMiller's Avatar
Quote:
Originally Posted by TNM View Post
will check it out ASAP then copy the test on my mac and see how far I get in comparison.

What CPU may i ask>

Oh, and thank you VERY MUCH! I owe you one.
ASUS motherboard, windows 7 ultimate, i7 cpu, SSD OS Drive, 7200 usb 3.0 audio drive. AISOALL driver (remember my driver comment above)

To make sure we were just testing record and no other problems, I used the same I/O for each track and recorded silence.

Plugins are slate tape and slate mix rack.

Last edited by JonMiller; 25th March 2018 at 11:47 PM..
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump