CPU overload after deactivating a hardware insert

[Franklyn]

Sometimes I have a strange behavior in my ProTools Sessions with hardware I/O inserts.

I know that big Plug in chains and also Hardware I/O on the masterbus (or aux) are overloading the CPU fast, also when the overall CPU usage is about 50% - 70%

This is a known behavior. In this scenario the middle CPUs have more big spikes.

But one thing is very strange. In many of my Mix Sessions the CPU is getting totally overloaded after deactivating an hardware I/O.
And when I re-activate the I/O the Session is working fine again.

That makes absolute no sense.

Does anybody else have seen this? Any Idea?

Thanx
Frank

[Darryl Ramm]

CPU errors or just meters in Pro Tools moving?

What you are describing may be a symptom of denormalization. What plugins are near the start of those chains?... and seeing the very low input input level values that cause denormalization... when you disconnect an input. I would hope that has been engineered out of most plugins but maybe not... you can play deactivating those plugins to find the culprit(s). Or you can try putting a dither plugin at the start of each chain.

[Franklyn]

CPU overload and 9173 error.

I will test deactivating the other plugs on the masterbuschain

[Franklyn]

Originally Posted by Darryl Ramm

CPU errors or just meters in Pro Tools moving?

... and seeing the very low input input level values that cause denormalization... when you disconnect an input.

I dont understand this phrase? :)

[Darryl Ramm]

Originally Posted by Franklyn

CPU overload and 9173 error.

I will test deactivating the other plugs on the masterbuschain

Do you have plugins that are now receiving no or very low input when you make those changes... they are the ones to focus on... not usually on the master bus... since that should have decent signal levels at all time. If not then this is not a denormalization issue.

You can google about denomination, it's well discussed on the Web, and on DUC in the past. It is the significant increase in floating point processing overhead caused when dealing with very small numbers.... like in plugins with silence or near silence as input. A dither plugin is usually enough to get them out of that regime... stick it a low bit depth to be sure when you test.

[Franklyn]

Originally Posted by Darryl Ramm

Do you have plugins that are now receiving no or very low input when you make those changes... they are the ones to focus on... not usually on the master bus... since that should have decent signal levels at all time. If not then this is not a denormalization issue.

You can google about denomination, it's well discussed on the Web, and on DUC in the past. It is the significant increase in floating point processing overhead caused when dealing with very small numbers.... like in plugins with silence or near silence as input. A dither plugin is usually enough to get them out of that regime... stick it a low bit depth to be sure when you test.

Thanx.

I found no Plug ins that make this problem or has strange input value.
Maybe I still haven t found the right one. I deactivated Sansamp, because this was described as one of those who makes problems. makes no difference

Maybe this makes it more clearer:

1. In the session the CPU meter jumps half the time on 100%/overload(red), but the session works fine without stops. (ignoring pops and clicks is not enabled)

2. when I deactivate the hardware I/O on the masterbus the sessions don't play anymore, not for a second (aae -9173)


3. when I activate the I/O again. everything works fine again.

this sounds like the denormalization issue, or?

(when I deactivate 2-3 CPU hungry plug ins on the masterbus the session works also with the hardware I/O deactivated.)

[Darryl Ramm]

Well no that does not sound like denormalization. That would only happen if changing something lead to a very low (close to nothing) signal appearing at the input to some types of plugin. And I'm not even sure it's much of a possibility nowadays. Sorry if I sent you on a wild goose chase I had a different picture in my head for what you were doing.

There have been occasional reports of CPU errors and hardware inserts over the years. Some triggered by adding the insert, especially at very low buffer levels, and some reports that sound like yours when removing them. I could not find the one I was thinking of but found this. https://duc.avid.com/showthread.php?t=380877 and https://duc.avid.com/showthread.php?t=401017

I'd hope other folks might have ideas, the rarity of this makes me wonder if corrupt sessions could be happening to some people. And since I am pretty sure this has happened to some folks with UAD plugins in the past (can't quickly find those posts now) that may be a factor. Are you using UAD plugins on that master bus? In that session? Is your IO buffer set as large as it can be? What happens if you remove those plugins? Or try a quick brute force test of move all UAD plugins out of the plugin folder. What happens if you move the insert to the other extreme end of the chain? Just for curiosity I might try disabling latency compensation (a wild guess based on the high latency of UAD and other plugins folks are likely to use on a master bus... but problem triggers *might* be very routing dependent as well, especially if that routing is forcing latency comp to do much.).

[Franklyn]

I think I found out why this happend. and it offers me a cool way of getting more power out of my sysem.

Its not a bug and it dont depends on "bad" plug ins or denormalization.

I can recreate this in any session.

the thing is. when you interrupt the longest "overall" plug in chain in the session with an hardware I/O your system gets a little bit more power for native processing. this sounds strange in the fist moment. but an hardware I/O gives a native system an additional buffer size and a little bit more time for processing.

It is a known behaviour that plug ins on the maser bus are harder to handle for your CPU than on tracks. this is because the master bus is the point where the over all plug in chain is the longest.

try this. take a working session with a lot of plug ins on the masterbus without errors at this point. put more (CPU hungry) plug ins on the masterbus until your system bring an 9173 error. now try to insert an hardware I/O between the masterbus plug ins on the first half of the inserts (best at the first position) on your masterbus.
now there is a big chance that your system is running without 9173 errors. thats crazy but helps me to get big sessions working.

ok, you get an additional DA/AD process. but you can work with more plug ins on the masterbus. And If you like you can deactivate this I/O for offline rendering.