HDN Send to Bus, Input, and CPU Load

[Peter Baird]

Here's a behavior I've never seen before (but honestly never looked for it either). I was trying to map out how to use LLM in a session, so I created four tracks and bussed them to the active LLM path.

The first thing I did was to put channel strips on the track inserts and then toggle in and out of input while LLM was active just to see the inserts bypass. Which they did. Then I made sends to a bus feeding a verb, did the same input test. Same result--the sends bypassed when the tracks were switched to input.

But a second later the output started to mute randomly and behaving like the CPU was getting clobbered. I opened the System Usage window, and sure enough the total bar was red and bars 8 and 9 were almost full with all the other 14 bars lagging behind.

Thinking the load was caused in some way by LLM, I switched it off. Everything shifted, but settled right back where it was--LLM didn't seem to have any influence on the load. I toggled all the tracks out of input and the CPU load settled back to a much more reasonable 40%.

With LLM still off I re-enabled input on the four tracks and started eliminating sends. As expected, each time I set a track to "no send" the CPU load dropped, settling back again at 40% when all the sends were eliminated.

Next I instantiated sends on all four tracks going to a hardware output instead of an internal bus. Surprise! No added CPU load. Only sends sent to internal busses cause this behavior. The other thing to note is that when LLM bypasses the send the CPU load is not reduced--it can only be reduced by inactivating or eliminating the send entirely.

Here's my takeaway: when recording, whether using LLM or not, any channels that are in input and have active sends to internal busses will place a significant load on the CPU. I'm pretty certain I never saw this on HDX with several hundred tracks in input and lots of sends everywhere.

On a related note, if you try to cheat LLM by having a pathway with multiple destinations LLM will not allow the channel output to go anywhere but the primary declared output. I noticed this because my "Monitor" path is mapped to speakers and to an external meter set, and when LLM is enabled it kills the meters. I suppose that's to be expected.

Peter

[Chief Technician]

Have you reported this at protools.ideascale.com?

[JFreak]

I can't say I haven't experienced this, but with some OSX&PT combination it may have been reality. As for now, things are looking smooth with latest&latest

[Darryl Ramm]

You could have been having denormalization problems from the plugins you are using. Especially if you were not really feeding any of them signals. Try different plugins or try sticking a dither plugin in front of them.

[JFreak]

Darryl has a valid point. Try removing all plugins ans see if this routing has a problem. If it goes away, the real troible is with a plugin

[albee1952]

FWIW, I haven't used LLM in many years. With the buffer set to 64, I have never had a latency issue, and I need to use plugins and sends while tracking so LLM is not an option for me anyway

[JFreak]

With buffer set to 256 (@48k) I have had very little issues since 2002

And 99% the time when I had an issue, I just took a moment and said it's fixed (without doing anything) and almost every time everything was allright

[YYR123]

Originally Posted by Peter Baird

But a second later the output started to mute randomly
Peter

This has happened to me with LLM before....I closed the session and reopened and it went away.....

But mine wasn't random, it was constant....I couldn't get any sound back out of the channel

[Peter Baird]

I haven't checked every permutation of every parameter. I'm simply reporting observed behavior within an existing session. And yes, I did trash the plug-ins folder and have Pro Tools rebuild it with only the basic set. No different, and I wouldn't expect it to be different since I don't see this behavior in HDX. If the problem was a rogue plug-in you would expect to see it across platforms and be subject to the dither workaround. It isn't.

Once again, the boundaries of this behavior are: HDN, tracks feeding a plug via a send to an internal bus, and toggling those tracks in and out of input. You can remove every plug in the session except the one the tracks are feeding and you will see the same thing: when tracks are dropped into input, the CPU load goes up. Depending on the destination plug it may be incremental, or it may be significant. This is not a deal breaker or an IdeaScale level problem. It's just one more little thing to be aware of when using HDN: When tracks with internal bus sends to a plug are switched to input the CPU load will rise.

That's it. Has nothing to do with LLM, I just discovered it while playing with LLM.

Peter

[Darryl Ramm]

Originally Posted by Peter Baird

I haven't checked every permutation of every parameter. I'm simply reporting observed behavior within an existing session. And yes, I did trash the plug-ins folder and have Pro Tools rebuild it with only the basic set. No different, and I wouldn't expect it to be different since I don't see this behavior in HDX. If the problem was a rogue plug-in you would expect to see it across platforms and be subject to the dither workaround. It isn't.

Denormalization bugs won't happen on HDX/DSP plugins. it's the plugins interacting with a "feature" of the Intel processor. Trashing your plugin folders may not be an effective test in this case (but a good one in general), you may be using Avid standard plugins with denormalization issues. Removing the plugin instance/insert or putting a dither plugin in front of them are the tests to do for this. If you've tried dither then that pretty much excludes denormaliation.

What exact plugins does this happen with?