AAE-9173 - Ran Out Of CPU Power

[Southsidemusic]

Extremely seldome in 12.4 HD so of you're looking for a stable version I'd say try 12.4. A Joy for those with errors. We are thelucky few that use 12.8.2 on both Sierra and High Sierra with absolute perfection so far

[TOM@METRO]

I agree with Christopher. Give 12.4 a try.

You won't have Collaboration in that version though, in case that matters to you.

[Guilla]

Originally Posted by TOM@METRO

I agree with Christopher. Give 12.4 a try.

You won't have Collaboration in that version though, in case that matters to you.

Apparently the CPU spikes didn't happen on HD system, only Native.

[Darryl Ramm]

Originally Posted by Guilla

Apparently the CPU spikes didn't happen on HD system, only Native.

Let’s be careful with product naming here or this will immediately confuse people. The tests did not show the the same issues with HDX systems (which run the Pro Tools mixer on the HDX DSP, which likely explains the difference).

[Guilla]

Originally Posted by Darryl Ramm

Let’s be careful with product naming here or this will immediately confuse people. The tests did not show the the same issues with HDX systems (which run the Pro Tools mixer on the HDX DSP, which likely explains the difference).

You're right my mistake I answered a bit too quickly.

[Studio Llama]

It's hard to know whether this is a Mac hardware issue and the solution is to buy a new MBP, or whether it is PT 12 and I'll have the same issue with a new machine.

Have tried v 12.4 again just now, same issue, have been through many iterations of OS and PT combined.

[Darryl Ramm]

I was looking back in this thread and was playing around with the test session posted here before

http://duc.avid.com/showpost.php?p=2454556&postcount=26

And I'm focusing on that tests session here, I would not assume that all the problems people are describing in this thread are related.

In that test session I first deleted all the audio tracks except one and left a signal generator inserted on it and played with Aux tracks fed from that one track with Pitch Shift II plugins on them.

The number of plugin instances supported depends on how you insert plugins on the aux tracks. In my case I filling up all the insert slots with Pitch II instances on an Aux track before moving to the next track and filling up it's insert slots. If you spread the plugins across more Aux tracks with less plugins per track you'll get less total plugins running. One example of why it's difficult to make comparisons with these sorts of things without being very careful. And obviously this is somewhat subjective anyhow, as different people will very how hard they push towards CPU errors.

The test session given had 15 Aux input tracks chained serially together though busses 1...15. The long serial chain here seems to be a clear cause of problems. If instead of having having all aux tracks chained one after the other I split up the chains into 3 busses long each before going to the same output you can get many more plugins running.

And the next obvious question is is there anything special about Aux input tracks or does an input monitoring armed audio track behave the same as an Aux track. I'll ruin it now and says it behaves exactly the same.

I've included screenshots of some tests here, showing the loing singe chain of Aux tracks and the meultipel sets of chains of sets of three tracks.

Results for all those tests are....

AUX INPUT TRACKS
-----------------------------------------------------------------------------------------------------
ALL AUX TRACKS CHAINED IN SERIES
80 Pitch II Instances, at 1024 sample (10 each Pitch II plugins on the first 8 of 15 total Aux Input tracks).
70 Pitch II instances, at 128 sample

AUX TRACKS CHAINED IN SETS OF THREE
300 Pitch II Instances, at 1024 sample (10 Pitch II plugins on each of 30 Aux Input tracks)
250 Pitch II Instances, at 128 sample

AUDIO TRACKS WITH INPUT MONITORING ENABLED ON EACH TRACK
------------------------------------------------------------------------------------------------------
ALL AUDIO TRACKS CHAINED IN SERIES
82 Pitch II Instances, at 1024 samples
62 Pitch II Instances. at 128 samples
(but at 128 becomes quite unsable, can be distrubed by using Chrome web browser etc.).

AUDIO TRACKS CHAINED IN SETS OF THREES
285 Pitch II Instances, 1024 samples, hyperthreading enabled, 8 virtual cores.
245 Pitch II instances, 1024 samples. hypergrheading disabled, 4 physical cores

Test system:

Pro Tools 12.8.2 R2 (A very clean install, Avid Complete Plugin Bundle and only few other plugins installed).
Playback Engine: Built In-Output
Buffer size: 1024 samples or 128 samples, noted above.
Dynamic Plugin Processing: Off
Ignore Errors: Off
MacBook Pro 15" Mid 2016, 2.9 GHz quad core i7, 16 GB RAM, Radeon Pro 460 (GPU switching disabled).
macOS Sierra 10.12.2 (was a clean install reinstall not an in-situ upgrade)
Everly last optimization done as per the book, except WiFi on, Spotlight off.

-----

Pro Tools is overall less stable at 128 sample IO buffer, e.g. clicking between tabs in a Chrome web browser might cause a CPU error to be thrown in some of the tests with the number of plugins mentioned above. Trying a high plugin load a few times at even smaller buffer sizes resulted in Pro Tools crashing (complete crash not caught as a AAE error, and since that's not an intersting point to run lots of plugins anyhow I gave up).

I don't use Pitch II, with DVERB the apparent CPU load reduced to something like 1/3. I did not push it to see the max DVERB instances that could be run. it's going to be a lot more. Pitch II also results in horrific delay of 40000+ samples with a stack of 10 instances on an aux track. Enabling or disabling delay compensation did not affect results here.

Playing with Xcode Instruments to disabling hyperthreading showed that the long-single chaing s not using CPU cores efficiently,

While disabling hyperthreading with the long singe chain of Aux or Audio tracks did not improve delivered performance it showed that things are not scaling well. With one long chain of tracks disabling hyperthreading delivers about the same performance (e.g. ~80 Pitch II instances at 1024 samples). If I then disable two actual cores so Pro Tools is only running on two cores I get almost the same performance as 4 cores (or 4 cores with hyperthreading). The Pro Tools CPU meters for individual cores are not consistent across these measurements, reflecting in particular that hyperthreading makes nonsense of Pro Tools CPU meters. With multiple shorter aux or audio track chains disabling hyperthreading gave a very slight decrease in performance and dropping from two to four cores showed a significant decrease in performance. It sure looks like long sequential chains of tracks when there are in real-time input mode (e..g using the playback engine set buffer, not the fixed disk buffer) cause problems with CPU scaling and ability to effectively use multiple cores.

-----

I guess the only take away here may be if you are using long chains of busses try changing to shorter bussing chains and see if that helps. Better testing here would be to see if say two separate long chains of Aux or audio tracks use more than two cores efficiently, that something I'll get to later. It would also be interesting to compare this long bus chain/short bus chain behavior on say a 12 core system, if it was only using 2 cores at most equivalent with these long-bus chains that would be sad.

I have no idea how useful Pitch II is as a load, I'd rather spend time playing with more real world sessions that are causing problems.

And while there appears to be some poor scaling shown I'll also note several plugins mentioned in this thread that can be problematic (e.g. Slate). I hope folks having problems have tested fully removing those plugins from Pro Tools, looked for denormalization issues with other plugins, trashed prefs etc. I'd also hope track freeze and commit work as options to reduce load work for people.

Some screen shots:

80 Pitch II Instanced running with one long chain of Aux tracks. 1024 sample buffer.
Long_Chained_Aux_Mix.jpg

286 Pitch II instances running with multiple chains of 3 Audio tracks (input monitoring enabled). 1024 sample buffer.
Short_chain_Audio_1024_mix.jpg

CPU Meters during that 286 instance test above.
Short_chain_Audio_1024_cpu.png

[wonder6oy]

Indeed, it is the combination of the length of the Aux bus chain and whether or not any heavy processing is taking place on that chain. And it is definitely an issue with Native systems only (HD or Vanilla).

After weeks of waiting, I got a generic "low latency processing increases CPU usage" response from Avid. Case closed.

As I don't have the time to deal with this any longer and don't get any indication that the Avid engineering team is going to regard this with any amount of seriousness, I began the transitional process to another DAW a couple of weeks ago. It's a painful one, but the results have been undeniably positive so far.

20 years invested in Pro Tools.

[john1192]

Originally Posted by wonder6oy

Indeed, it is the combination of the length of the Aux bus chain and whether or not any heavy processing is taking place on that chain. And it is definitely an issue with Native systems only (HD or Vanilla).

After weeks of waiting, I got a generic "low latency processing increases CPU usage" response from Avid. Case closed.

As I don't have the time to deal with this any longer and don't get any indication that the Avid engineering team is going to regard this with any amount of seriousness, I began the transitional process to another DAW a couple of weeks ago. It's a painful one, but the results have been undeniably positive so far.

20 years invested in Pro Tools.

which DAW are you moving to ???

[wonder6oy]

Originally Posted by john1192

which DAW are you moving to ???

S1