CPU spike- Catalina / 2020.5

[rockafella]

I've already had one interesting finding - using OCCT to test, which I usually don't use for stress testing as Cinebench and Prime95 usually will find unstable overclocks much more often - it seems to stress the CPU in a way that Pro Tools still shows near 100% and errors out, but the computer also is less responsive. So, it seems to be the sort of test, as well. Could be use of AVX, or not AVX, or the types of instructions it tests with.

For example, Cinebench always makes the CPU very hot, not as much as Prime95, but much more so than running OCCT; but it never has made my computer unresponsive, other than perhaps when it first starts running the test and is preparing.

I'll look sometime for a less intense CPU test. I did try just two cores in OCCT, but that didn't help. All cores on a random pattern, but then the CPU usage in Pro Tools comes and goes in waves (literally looked like an EQ curve as it came and went).

But again, kind of pointless, just proves to me that one can click Ignore and try to forget any of this testing happened. :)

[Darryl Ramm]

Originally Posted by rockafella

I respect Ramm's thoughts and he's had plenty of great messages on here, but I agree with you, Pro Tool's CPU meter is garbage.

I'm not sure what you are picking up on here exactly with the disagreements in this thread but I would never want to be seen to argue that the Pro Tools CPU meters give a simple or accurate view (and accurate to what? what exactly are they supposed to show?) of what is going on. There are hundreds of posts on DUC of me warning people not to fixate on the CPU meters or say worrying about asymmetric load distribution... especially those folks who stress about that and don't have any actual CPU errors.

CPU plugin processing improvements and CPU meter improvements in 2019.5 helped some workloads (esp. long processing chains) significantly, and gave us a bit better metering but I am sure there are still issues.

And yes there can be fundamental issue with displaying CPU utilization in a hyperthreading environment and just exactly what that actually means.

Experienced plugin developer Michael Carnes wrote an article about the problematic CPU metering for Pro Tools expert. https://www.pro-tools-expert.com/hom...d-be-pay-to-it And see this thread https://duc.avid.com/showthread.php?t=410987. It still bugs me that many years ago one of the Avid engineering directors who was great and hung out on DUC helping out with more technical questions was going to write some stuff up about metering but he bailed out of Avid before getting to do that. I really wish we had a knowable explanation available.

[rockafella]

Originally Posted by Darryl Ramm

I'm not sure what you are picking up on here exactly with the disagreements in this thread but I would never want to be seen to argue that the Pro Tools CPU meters give a simple or accurate view (and accurate to what? what exactly are they supposed to show?) of what is going on. There are hundreds of posts on DUC of me warning people not to fixate on the CPU meters or say worrying about asymmetric load distribution... especially those folks who stress about that and don't have any actual CPU errors.

CPU plugin processing improvements and CPU meter improvements in 2019.5 helped some workloads (esp. long processing chains) significantly, and gave us a bit better metering but I am sure there are still issues.

And yes there can be fundamental issue with displaying CPU utilization in a hyperthreading environment and just exactly what that actually means.

Experienced plugin developer Michael Carnes wrote an article about the problematic CPU metering for Pro Tools expert. https://www.pro-tools-expert.com/hom...d-be-pay-to-it And see this thread https://duc.avid.com/showthread.php?t=410987. It still bugs me that many years ago one of the Avid engineering directors who was great and hung out on DUC helping out with more technical questions was going to write some stuff up about metering but he bailed out of Avid before getting to do that. I really wish we had a knowable explanation available.

Hey, thanks for responding... guess I misinterpreted some of the previous discussion, no worries. Yes, I had seen those also.

Anyway, I couldn't let it go on mine, and after a couple dozen more restarts, I pinned it down to setting all C states to disabled (which I'd tried before), but also another C state setting which by default is "no limits" - since that sounds good without realizing it's the inverse, I don't think I'd tried that one! Once I set that to C0/C1, I can now play my same simple session with the instrument track record-enabled, and my overall CPU meter in pro Tools rarely goes over 8%, and usually around 3% (and 0-1% on playback without the record-enabled track).

HOWEVER, even though it never visibly kicks above 20% (and that's very rare) - it will STILL stop playback sometimes! (although only after ten minutes or so)

So, in the end, I am still going to follow my advice, click the ignore checkbox, and forget about it - but at least the CPU meter looks realistic now. :) (and I wonder if anything else about the UI or the snappiness of playback improved - probably imagining it, unless Pro Tools bases any other internal decisions on its CPU meter)

I am really curious HOW it measures the CPU - I am guessing some very old way from before many C-states existed? I did notice in my testing, for example, that simply disabling C6/C7 improved it by at least half (and the rest of the other C-states brought it all the way down). Maybe it's doing some very short timing thing, and hitting a parked core, then thinking it's loaded down just because it takes that tiny bit longer to wake up and respond?

I am going to try putting an ATI RX570 card in, also - downgrade from the 1080TI, and LatencyMon doesn't really show it going over 100 often, but I figure it's worth a try just to see if the latency figures get any better.

But yeah, will just set that checkbox again and truly forget about it this time! (I wish there was an option for 64 samples at 96kHz on HDX - I am pretty sure many modern systems could handle it, for small to mid-size sessions anyway. Unless something about HDX imposes that one-buffer-size-higher minimum vs Native?)

[Rectifried]

Originally Posted by Darryl Ramm

Please follow the DUC rules and do not create multiple threads like this, you should reply to your previous thread, which will also often help you get better assistance.

[Could a mod merge this thread with http://duc.avid.com/showthread.php?t=410607]

---

Basic things to look for here are covered in many threads on DUC and under "help us help you" up the top of each DUC web page.

Is your system fully optimized? do every last thing no matter how painful for now. You can back off later, but for now do it all, including disable bluetooth, disable wifi, etc.

What IO buffer size and sample rate are you running at? If you can set it to a large size that is stable, then reduce until it becomes unstable and do more troubleshooting at that buffer size trying to get it more stable.

How did you get stuff setup on the new Mac? Did you use the system migration utility to migrate from your old Mac? What did you move with that utility? What apps and plugins and drivers did you install from scratch?

What audio interface and driver version?

Where are you recording sessions to? (disk issues can cause CPU errors).

Make sure your disk cache is set to a few GB not "normal". I assume that will fully caches your sessions.

The run thought, testing after each step:

Trash prefs using Peter Gates utility. (and keep doing this between other tests).

Move all .aaxplugin files out of the plugin folder (/Library/Application\ Support/Avid/Audio/Plug-Ins). And Trash Prefs again. Pro Tools will put back the default plugins when it starts. (And importantly it does not only matter if you use any plugin in your session or not... we care if you have removed all third party plugins installed on your system (and potentially all Avid plugins if you have incorrectly upgraded Pro Tools)... plugins don't need to be instantiated in your session to cause all types of problems, they just need to be installed in Pro Tools).

Test using Build-In Output as the playback engine

Test starting with an empty session, not from a template.

Create a new macOS Admin User and test from that account.

At this point test it all, from this account, with all third party plugins removed, using built in output as the playback engine, with a new amptu session, after trashing prefs etc.

You might want to try a clean reinstall of macOS and clean install of Pro Tools and ILM and nothing else at all and see if that works... do that on test container on your boot drive (if you are comfortable with administering the system/APFS disk management) or on a external SSD.

And if you get this far and are still stuck you should be opening a support incident with Avid.

I'd also be sure to turn off remote telemetry since it's known to cause other issues on 2020.5.

If this is a new MBP 16" I think they only ever ran Catalina so worrying about getting an installer off Apple is a waste of time. Chasing Apple and running tests on the Mac hardware is likely a waste of time. You have lots of basic troubleshooting to do before suspecting the hardware.

These are great ideas... and with some ppl they will help..
But anyone in the game "for a while" prob knows much of this... good to post so thx
The issue I think,, yes I, is that
A] these same plugins [mostly major co] work FINE in other daws
B] I have had "Temporary" reprive from the -9xxx taking out things

only to have it creep back.. then thinking on this day this ones the culprit... one this day that one is... whack a mole.. hours spent, with Mr PT and Im NOT WORKING



Taking out ALL non PT plugins.. yes would prob be "faster"
but cmon... these thing work in 4 other DAWS.


PT is sloppy and ...
Look, I could never get my buffer down below 128 before... then they have CARBON and 2020.12... and now 64... even 32
so Yeaah great AVID you get a lollypop!!!.. Thx Buuudddie


BUT why did it TAKE TRYING TO SELL a NEW HW to FIX THIS.
AS it could have been "streamlined " YEARS AGO
Am I missing SOMETHING?


on PT 21 years BTW

[rockafella]

Originally Posted by Rectifried

A] these same plugins [mostly major co] work FINE in other daws

Taking out ALL non PT plugins.. yes would prob be "faster"
but cmon... these thing work in 4 other DAWS.

From my perspective, being newer to Pro Tools, it's been refreshing having a different plugin format - very quick to install, and I KNOW they will always go to the one and only true installation path, instead of worrying about setting VST paths or where they might choose without letting me decide (and each manufacturer changing their path and whether they use subfolders or not on each of their individual plugins). *I guess VST and especially AU on Mac has the same benefit though...

That said, your point is definitely valid - I have been disappointed that my Rob Papen plugs that I just finally go around to buying on the holidays seem to not only not work, but crash my Pro Tools. Haven't gotten around to debugging that one! (might be better to just host the VST in one of the wrapper style plugins)

On the other hand, every other plugin has worked fine, for me (and I have a LOT of third party plugins - way too many). I think a few were duplicating the AAS Player in different locations, which threw my VST hosts for a loop, but again, that sort of thing can't happen with the dedicated AAX path.

On the buffer size - I think this is probably their holdover from the old days... I mean, a decade ago, sure, MAYBE you could start off at 64 at 44.1 kHz, for a few tracks of audio and very little plugin processing - but very soon after you would need to bump it up to 128, right? (or maybe not - I wasn't doing too much with DAW recording at that point, vs. before and after) I agree though, would be nice to have the option. (especially on HDX, kind of annoying I can't at least try 64 at 96 kHz using the HDX card, to see if I can get the total round trip to sub-1.3ms - that said, this is so real-time already, it really feels like not only a digital mixer, but an analog one, and, having never used HDX before, this was a very pleasant surprise)

My complaints are more with the other random issues such as the CPU metering that was my point in my messages, and then just yesterday I had the bug where it kept restarting every time I closed it. But there are just so many editing features, and laid out in a way that is actually approachable, that I am happy so far. (and the EuControl surfaces - finally, integrated surfaces that actually work and are useful! have tried many other MIDI control surfaces over the years, never used a single one of them, until this one)