How to Optimize PT for CPU.

[musicman691]

Originally Posted by albee1952

Most Mac users I know have better luck if they assign 1 less core to Pro Tools than the system(so an 8 core system would have 7 cores allotted to PT)

Can't do that for PT11.

Something that will help spread out cpu usage with vi's is instead of loading up a single instance of say Kontakt with multiple instruments is to use individual Kontakt instances for each instrument or set of articulations. Say you want violins - use one instance of Kontakt to run all the articulations you need for strings - staccato, legato, marcato, etc. Do the same thing for say trumpet.

[aylavid]

Originally Posted by Chief Technician

This is only partially true. When using HDX, the Avid Audio Engine (AAE) has direct hooks into the HDX card. All of the audio stays in one domain (DSP) until you instantiate a native plug-in.

When using UAD plug-ins, Pro Tools thinks you are using native plug-ins. Even though the UAD plug-ins will be running on UAD DSP, they will still be subject to all of the issues associated with running native plug-ins in Pro Tools.

How much RAM is installed in your computer, and if you are running Mavericks or later, do you see any red in Activity Monitor's (/Applications/Utilities) Memory Pressure graph?

Dear Chief Technician Jonathan S. Abrams,

Thank you for the reply.
When the time overload message started to appear often, We asked UA
to make sure all plugs are depending on DSP 100% because the message says "remove the native plug-ins" and all UAD plugs shows "Native."
And confirmed 100% DSP and never use host CPU.
However, I feel what you are saying is also true. So that since the PT thinks all plugs are Native, but the PT doesn't find HDX card. So then perhaps host CPU kicks in some %?
How do you HDX user use UAD system? Do you combine both HDX units and Apollo?

Regarding RAM, 16GB our Mac has, and they look just average.
Here are the consumption of CPU and RAM. (s.shots)

You have mentioned about Windows is more flexible regarding CPU control. We had been Windows user until few years ago. It was prosumer computer fixed by Sony. We didn't use Pro Tools back then.
Since we installed Mac to our system, we have more trouble. They update OS too often, and bugs come with. In my experience, Windows are more stable. We are now considering perhaps better going back to Windows PC. We need to find out if the PC is compatible with Thunderbolt right now.
Do you hear anything good between PT and PC?
Everyone I know is Mac user in US and Japan. I have seen some people in Europe using PC. Also, as you know all Mastering engineers use PC because of the DAW they use.
It is helpful giving us your opinion regarding using PC with Apollo and Pro Tools, etc. in the professional field.

Thank you for your help,

[aylavid]

Originally Posted by musicman691

Can't do that for PT11.

Something that will help spread out cpu usage with vi's is instead of loading up a single instance of say Kontakt with multiple instruments is to use individual Kontakt instances for each instrument or set of articulations. Say you want violins - use one instance of Kontakt to run all the articulations you need for strings - staccato, legato, marcato, etc. Do the same thing for say trumpet.

Dear musicman691,

Thank you for your advice. Do you know how to make PT to using CPU spread to 8 threads evenly??

[aylavid]

Originally Posted by albee1952

Most Mac users I know have better luck if they assign 1 less core to Pro Tools than the system(so an 8 core system would have 7 cores allotted to PT)

Dear albee1952,

Thank you for your tip. Yes, I have heard that assigning 1 less core to PT before. But I am not sure why and how.

[aylavid]

Originally Posted by The_Skywalker

I've received this error on my mac book pro but it was mainly due to insufficient power (battery life) I doubt this error is due to that. Have you tried running this same session in another computer? Possibly a less or more powerful one? Could it be that your session is corrupted? Or does this error appear with every session?

Dear Skywalker,

Thank you for your reply. Currently, we don't have another computer to test this. We will watch out other sessions if they get the same message.

Thanks again.

[musicman691]

Originally Posted by aylavid

Dear musicman691,

Thank you for your advice. Do you know how to make PT to using CPU spread to 8 threads evenly??

I just told you how to do it when using vi's (virtual instruments). Other than that there's no way to spread things out evenly amongst the cores that I know of. There's been some talk about hyperthreading versus non-hyperthreading and evening things out but it doesn't work for everyone.

[Chief Technician]

Originally Posted by aylavid

How do you HDX user use UAD system? Do you combine both HDX units and Apollo?

I do not know if UAD and HDX can be used on the same system. I am not a UAD user. I think UA clams their card can be used with HDX. That's a question for them.

As for Windows being better, I don't think it offers users like us any more control. I think offers developers (Avid) more control over how hyperthreading is used. Whether or not Avid is taking advantage of that is another matter.

[darbyclash34]

The spike on CPU 4 is fairly typical in my experience. I believe it has to do with OS scheduling, most computer takes are either not conducive to parallelism (the result of step B depends on result of step A, therefore A most be done first and can't be sent to another core to execute at the same time) or the benefits of would be outweighed by the negatives (CD ripping's bottleneck is the data transfer rate of the optical media, so while you could have a core ripping and a core encoding to MP3, etc, there's no point since the encoding thread would constantly be waiting for the ripping thread). Also, many lower end machines only have two cores with no hyperthreading, which is pretty much the entry level of modern computers. From Windows task manager and a program called Process Lasso, it seems like many system processes like to hang out on cores 1 and 2. Not sure if this is the scheduler, if this a programmed behavior, or what, but it's definitely pretty common. So my suspicion is that the bump on thread 4 of 8 (which I believe would be the "hyper" thread, IRRC the odd numbered cores are the "real" cores and the even ones are the "virtual" cores, although modern hyperthreading makes this distinction less important) is the main audio thread parking itself on a core that it suspects most programs aren't going to mess with much. Make a core appear so busy to the scheduler that the scheduler doesn't send any other work to it. Something like that. I could be wrong, but that's the only thing that makes sense to me as to why it does that.

One thing I have found is that many Pro Tools errors that reference CPU are relics of days when CPU was the biggest hurdle, and don't always tell you the right info. As mentioned above, the 9100 errors are generally audio not getting where it needs to go fast enough. While the CPU is definitely one place that could happen, other things could also cause it. The most common issue is with bad plugins, including some built in ones. The SansAmp plugin is famous for its de-normals, where the CPU is trying to calculate incredibly low level signal and it takes a ton of CPU time. As mentioned above, NI VI's have done it, particularly sample based ones. Good place to start with that is taking all the plugins out of the Pro Tools plugins folder and then add them back in one by one.

Another commonly overlooked culprit is your audio interface or its drivers. Particularly with low latencies, the quality of your driver and interface are seriously tested, and brands like RME tend to offer the best performance levels. What interface are you using?

Do you have the issue at 48k? Every process uses a lot more CPU time, and you're generating a lot more buffers. 2048 at 96 is the same amount of time for each buffer as 1024 at 48. Plus, using 32bit files, each sample is 33% larger than 24 bit. So, you can be in a spot where while you have the CPU to process it, between your drives, memory, busses, etc, you can't get the audio there fast enough to do so. I would experiment with 48 and 24 bit files to see how your machine performs with less data to deal with.

Few thunderbolt interfaces are supported under Windows currently, the only one I can think of is the Aurora Lynx, I know the new Focusrite Clarrets say Windows support is "coming". This should be changing somewhat soon, in the Windows 10 now has native support for Thunderbolt 3 audio devices (the lack of this built in driver was cited by UA as a reason for the Apollos not supporting it). But, this is currently Thunderbolt 3 only, it'll be up to developers what else gets supported. I am personally waiting on a Thunderbolt 3 interface to come out for future proofing.

Hope some of this helps.

[aylavid]

Dear darbyclash34,

Thank you for the great information.
Are you computer scientists or engineer? How come you know much about the computer?

Surprising to hear spiking CPU 4 is typical. And as you say, I also believe 4 is the hyper thread of physical 3.
Could it be some "OS error" because CPU usage belongs to Mac OS scheduling and not controlled by Avid? or just a Bad scheduling of Apple.

I have always been curious that why Avid doesn't provide us accurate information on CPU compatibility of Pro Tools that how many cores and clock we need. I strongly feel they should. However, if this matter belongs to Apple as you say, Avid can't do anything about it.

We recently got an error of AAE 6101. Do you know what this mean?

I have seen often people are discussing regarding more Cores or Clocks.
How do you consider this? Usually more cores, single gets slower.
So often people often chose at middle like 4 or 6 core machine.
We often work high sample 96khz & 24 or 32bit f recorded, but tracks are usually not so many, within 20. And since our CPU usage shows an unbalanced way, using 3, 4, 5 thread mostly, can't help thinking we need high single clock = 4 or 6 cores rather than 8 or 12 slow single cores.
What do you say?

Compatibility of Daw and Mac CPU must be best on Logic Pro because they both from the same company. We haven't tested this project on Logic Pro because we don't have Logic Pro X. Logic Pro 9 that we have is not properly working with new OSX.

Thank you for the information on Windows PC. Do you have experience using PT with PC? If so, is it stable?
We are very curious about the usability of windows and audio interface and PT.
One good thing with PC is that Sequoia is available.

Thanks again,

[darbyclash34]

I'm flattered you thought so, but I'm not a computer scientist, although I worked with a bunch of really smarts at a certain fruit company... Most of this comes by doing and reading, when my parents got my brother and I a 486 dos box, no one else was gonna figure out how to use it and fix it. When I started recording bands at about 15 or 16, doing it on a computer seemed like the way to go, but I was also lucky enough to train and intern at a really awesome tape based all analog studio, so I got the best of both worlds in my opinion. Nowadays a lot of my business is installing, configuring, and support recording systems, so I read voraciously to stay current and find new tricks.

The Core 4 phenomenon is definitely not an issue with Apples scheduler, as I get the same thing here. So one thing to keep in mind, and I'm not sure exactly when this changed, but hyperthyroid for isn't quite the same as it once was. On a modern quad core, most of the components are there for 8 cores. The difference is each pair feeds into a shared execution unit, which for a real time process, having to wait can carry a fairly heavy penalty. But for all intents and purposes it's equally OK to send the work to core 3 or 4, depending on which one is busier. This isn't the way it's always been, in the older hyper threading using the virtual instead of "real" core was a hit. A lot of programs still tend (either for backwards compatibility, the necessary code would be too difficult too thread properly or isn't all that threadable in the first place) code as if cores aren't equal, and tend to try to pile into the "real" cores (as much as the scheduler with allow). So my guess is that they're trying to grab a core that no one else is going to request, and since they share execution units, they'll ultimately wind occupying most of 3&4. I could be way off about this, but it's behavior that has occurred across multiple versions and across Mac/PC.

There is a lot about Avid's transparency that needs improvement. Myself and others have asked over and over again for an explanation of the dual buffer/dual latency domain system introduced in 11, advertised through a couple of versions of 12, and then all mentions seemingly vanish. From my tests, it CAN work, but it is not possible to use the feature as described by Avid. Blatantly false. If anyone out there can mix a song, then do a last minute overdub, all without changing your buffer, I'd love to look at the session. The feature is so limited as to be useless, and was definitely falsely advertised. But that's another rant.

About 6 months I guess I switched to Windows 7 from OS X 10.9.5 using a Hackintosh. I had been having very hard to isolate problems so I decided to take the variable of running an unsupported OS, plus DAWBench has found Windows outperforms at low latency. So I made the jump. My really weird problem actually came out to be a voltage and ram timing issue, I had replaced the ram but never loosened the RAM timings. Anyway, they both get the job done. I greatly prefer OS X in everyday usage, but my recording machine I look at as an appliance. I turn it on, record, turn it off. I really only see Pro Tools most of the time. I can't say if it's really more efficient all being equal, but the flexibility it allows in building and designing my machines, as well as the tweak ability of both hardware and software, is such a huge boon, I can't imagine buying an Apple desktop machine in the future. At the same time, my personal list of optimizations for Windows 7 for Pro Tools is pretty extensive (much beyond the Avid list), whereas on a Mac I basically just follow the Avid guide. So I think it depends on how computer friendly you are. I want a car that I literally never open the hood of. Others want to get in there and tweak. Different strokes for different folks.

As far as core count versus clock speed, for the sessions you're describing I would think higher clock and higher instructions per cycle would win out over core count. It's easier to keep channels on a single core versus doing the first insert on one, the second on a different core, etc because that doesn't parallel very well. Insert B needs to know the result of Insert A before it can start working, and if it's trying to do that on a second core, there's cache penalties to deal with, all sorts of stuff. Some virtual instruments spread across cores to some degree, but to my knowledge, an instance of any given plugin on any given channel is being processed on one core along with all the processing on that channel. So for you, I would probably go for the fastest 4 or 6 core. 8 or 12 I don't see helping you much. That's one area a custom PC kills the Mac, this summer I'll be upgrading from a quad core sandy bridge Core i7 2600k, stock it runs at 3.4ghz, I've got it at 4.2. I'm gonna go to whatever 8 core chip comes out with the summer refresh, liquid cool it so as to hopefully get em at 4.0ghz, and have the best of both worlds.

Long story short, most tasks prefer high clock speed and IPC over core count, but more cores are huge as you get into bigger sessions.