12.8.3 Cpu overload out of nowhere?

[mightyduck]

Originally Posted by dankin

If it is denormalization causing these issues, why are there so many plugins being made with this issue? Is it just bad coding by plugin manufacturers? Granted some of avids own plugins have had denormalization issues for as long as I've used PT. Sansamp for one. Is it really the issue causing the cpu errors in PT, or just another thing to pass the blame on to?

This.

[mightyduck]

I wish I had a dollar for every time Digi Tech Support had me trash prefs and reboot the computer, probably laughing and knowing all the while that the software was buggy.

MD

[Darryl Ramm]

Originally Posted by dankin

If it is denormalization causing these issues, why are there so many plugins being made with this issue? Is it just bad coding by plugin manufacturers? Granted some of avids own plugins have had denormalization issues for as long as I've used PT. Sansamp for one. Is it really the issue causing the cpu errors in PT, or just another thing to pass the blame on to?

Denormalization is only one issue that affects plugins, but if you see high or spiky CPU burn, especially when stopping the transport or pulling the input to a plugin extremely low, or just while futzing around... then it’s the go to suspect. I suspect it is far from causing most issues with CPU errors with AAX plugins... it’s just so easy to do anything in a plugin that causes a little latency and will throw a CPU error. Denormalization does not directly cause latency, it just makes the CPU processing so damn high compared to normal floating point processing that the plugin runs out of CPU earlier... and then suffers a latency problem that pulls over Pro Tools with a CPU error.

As for denormalization... I have long suspected just lazy development... aka it never being a product spec requirement/focus. There seems no reason for this having to be allowed to happen. Maybe made worse by abstractions like development toolkit’s that are keeping developers away from the low-level code. I would hope (as a developer who understands the Intel processor well, but outside audio work) that the toolkit’s would actually help developers protect against this (the simplest possibility is to just auto dither the data). Of course we could be paranoid and claim it’s all a ploy to sell more HDX hardware

What I noticed recently when trying to show somebody classic denormalization was I could not get it to easily happen, which had me a bit confused, I wondered if somebody had worked on improving stuff. 12.8.3 playing with Sansamp and DVerb.

Edit: missed MDs update post, that he does not have any plugins instantiated... then it’s not denormalization of course, but I would still exclude rogue plugins by moving all AAX plugin files out of the plugin folder, trashing prefs and trying again. A good quick test to confirm no third party plugins are going rogue.

And another reminder that this can happen with corrupt sessions, and I have seen whole sets of sessions cloned from one that had these type of weird issues. So try a quick test of creating an empty session and load up some of the same content.

Otherwise yes maybe it’s a HD Native and/or driver issue. May be interesting to play back the same sessions at the fastest sample rate that built-in output will support just to see.

Personally I would not work at more than 96 kHz due to the extra CPU load at no perceivable audio difference.

Sent from my iPad using Tapatalk

[ZEUSS]

Originally Posted by mightyduck

Hi,

O.K., here's an update.

In my system this is the exact language that comes back with the hang:

"Audio processing could not complete due to conflicts with other CPU tasks or a potential clocking issue. If this occurs often, verify your sync cables or try changing the HW Buffer Size setting in the Playback Engine dialog. In most cases, a larger HW buffer size will prevent the problem. (AAE -9093)"




MD

I have got this as well lately. Never have really before. Started with 12.8.3.
Also noticed some weird things with the graphics getting glitchy at times.

[fatjon22]

Also having this problem. Most easy to reproduce, adding the mini grand piano instrument to a MIDI track. Not even playing anything or recording, just added the piano, started loading, bar half way across and a CPU overload.

[TNM]

Originally Posted by mightyduck

Hi,

Thanks for your post, and I appreciate the help. In this case there are basically no plugins or VIs in the sessions. These are tracking sessions from projects done in major studios, with guitar overdubs on a number of them. So its just audio. Not a lot of tracks. There is no MIDI either on the stuff I've been loading.

I just got the system running, so I have been poking around learning the slightly new layout / look of the software. I stopped chasing updates when I got 7.3 running really good, and this is 12.8.3, so there are a couple of new bells and whistles.

I have seen the errors when messing around with the inserts, checking out plugins, but most of the CPU load seems to be related simply to the fact that the sessions are 192kHz.

Even with no session open at all, if I set it to 192kHz there is a good bit of activity in the system usage window. The "total" cpu meter seems to have a peak indicator as well, and that gets up to even 50% or so at times [just idling, no audio]. When I change the sample rate to 48 or so, things settle down to almost nothing.

The other thing that made a difference is toggling the buffer settings. I think I have it quieted down. Weirdly, it was set at 256, then I changed it to 128 and it was better. 1024 caused a huge surge, then quieter. But overall, just toggling the buffer settings made it better.

I think I'm used to working with a DSP system rather than this "Native" stuff. So I have never seen the computer have to work hard just because the sample rate is high.

The info on denormalization is helpful, thanks, but its probably not the real issue here.

I think the optimization stuff and trashing prefs and all that is good practice, but, in my experience, rarely solves the issues unless they are really minor.


Thanks,


MD

Hi MD.. i must have missed the 192 part.. wow... i guess it definitely has something to do with it!

On my macbook pro where i am right now i have the mbox connected so can not go higher than 96 to even do a comparative test for you to see if it's the same here.

But i CAN say, at 96K, which is much less processor intensive than 192, is bouncing the cpu meter around like crazy when i set it at 64 samples..

The weird thing is, this is a blank project with no effects, and one whole audio track LOL.. track is not monitor armed at all..so nothing is armed on the 64 buffer therefore pro tools is actually on it's internal 1024 buffer.. yet for some reason spikes.
Even weirder, after a few minutes it gets better.

But now i just inserted one instrument, an FM8, and armed the track, and it is dropping out when i play a few notes on the default instrument!

i think something is wrong with 12.8.3, as i was using 12.4 all the time with 64 samples at 96K or 32 at 44, and although much higher usage than 128 buffer, it was not dropping out all over the place.

Something has changed on the mac version when they updated the graphics system for high sierra and removed yosemite support.. I am sure of it..

I actually think what you are seeing is what is happening here.. I wouldn't even dare try compose a new song at 96K with the way the performance is now.. Unless I was at 256 buffer, only then it settles down.

This is the reason i want to move to HDX and windows..

With windows you can have a computer where there is no fluctuating clock speed which makes a huge difference particularly at 128 buffers and under..

Even if i stau on mac and move to HDX... that's not gonna help when i need to use VI's and native FX.. so.. still want the best solution for all worlds.

Anyway, i think what you are experiencing is simply that a macbook pro is not suited for 192k.. that's my best guess, and it is a guess.

[dankin]

Originally Posted by Darryl Ramm

Denormalization is only one issue that affects plugins, but if you see high or spiky CPU burn, especially when stopping the transport or pulling the input to a plugin extremely low, or just while futzing around... then it’s the go to suspect. I suspect it is far from causing most issues with CPU errors with AAX plugins... it’s just so easy to do anything in a plugin that causes a little latency and will throw a CPU error. Denormalization does not directly cause latency, it just makes the CPU processing so damn high compared to normal floating point processing that the plugin runs out of CPU earlier... and then suffers a latency problem that pulls over Pro Tools with a CPU error.

As for denormalization... I have long suspected just lazy development... aka it never being a product spec requirement/focus. There seems no reason for this having to be allowed to happen. Maybe made worse by abstractions like development toolkit’s that are keeping developers away from the low-level code. I would hope (as a developer who understands the Intel processor well, but outside audio work) that the toolkit’s would actually help developers protect against this (the simplest possibility is to just auto dither the data). Of course we could be paranoid and claim it’s all a ploy to sell more HDX hardware

What I noticed recently when trying to show somebody classic denormalization was I could not get it to easily happen, which had me a bit confused, I wondered if somebody had worked on improving stuff. 12.8.3 playing with Sansamp and DVerb.



Sent from my iPad using Tapatalk

The Sansamp and DVerb issue has always been hit or miss for me. I've definitely had issues with it at times, I rarely use Dverb unless it comes in on a session, but I still use Sansamp fairly often, and I see less issues with it now than I did back in the RTAS era. I remember some versions of PT, I think around 7 or maybe 8, where it was almost unusable for me because of the spikes. At the time I didn't know about putting a dither plugin in front of it. Didn't mean to derail the thread with the denormalization talk, it's just one of those things that's been a mystery as to why it still happens. I wish someone from Avid would chime in on these threads...I sometimes wonder if they are even trying to fix these error issues that so many have.

For me the CPU spikes have been a constant issue since 11. I have weekly conversations with other producer/mix guys in the Nashville who are having the same issues. I have noticed some of the spikes seem to be tied to graphics. If I have certain plugin windows open, particularly Sonnox Dynamic EQ, Fabfilter ProQ2, Pro-MB, or Pro-L2, I will almost always get a 9173. Is it tied to OpenGL? With the Sonnox at least, the same thing happens whether or not OpenGL is enabled.

[tamtamstudio]

Originally Posted by priorytools

Just piping in . .
I have just had system usage spiking up to 100% with no session loaded. .
I was working on some old 192kHz sessions. . some of which were running VSO vari speed up.
I rebooted & power cycled the Sync HD . .
All calm again in the system usage window. .
HHmmm. ?

Here the same.
No session open, CPU jump spikes from 4% to 100% all the time.
HDX on MacPro 5,1 High Sierra. Buffer 1024, no video engine.
I have to restart the OS as last chance and let's see..

[michael c]

Originally Posted by ZEUSS

I have got this as well lately. Never have really before. Started with 12.8.3.
Also noticed some weird things with the graphics getting glitchy at times.

Same over here. never had this before 12.8.3

[Rubberband]

Originally Posted by michael c

Same over here. never had this before 12.8.3

Same here "Audio processing could not complete due to conflicts with other CPU tasks or a potential clocking issue, increase buffer size blah blah..."

Running 12.8.3 and today upgraded to 2018.1, same on both

HDX, on High Sierra 10.13.2... 8 core 3.2ghz Xeon, 32 GB RAM.