[BUG] Inactive instances add load to active instances

[emkayg]

Description

Instantiated but inactive instances add signifcant load beyond their static load once a single track with NAM is armed. This is in Reaper in my case.

To reproduce

• create a track with NAM
• observe cpu load
• arm track
• observe cpu load
• disarm track
• create several more instances
• observe cpu load
• arm single track
• observe cpu load

Expected behavior

Arming a single track should be mostly the same whether other instances are instantiated or not. Instead, each instance adds a significant amount to the load of a single active instance. This quickly escalates to bringing down the system with several instances in a session.

Computer & other info

(please provide the following information):

• Windows 11
• Onboard graphics & version
• Plugin version 0.7.13
• VST3
• Reaper
• RME ASIO of any other audio driver
• Sample rate 44.1 kHz
• Buffer size all

further description and comments

1. it seems like instantiated instances increase rt useage even when no audio processes pass through them and stopped.
2. this gets worse when you record enable a track. Which is the main point of this report. Rephrased: It seems every OTHER track adds to the this single track load. For example, a single NAM record enabled track uses 10 percent, but for every additional silent NAM instance, the load jumps by an additional 3 percent when that one track is record enabled. So if there were 4 other instances with no audio passing through then, the total useage would be 24 percent. This is in addition to their static load in my previous point.

Somehow, each NAM instance (whether processing audio or not) adds a load to instances that are processing. Why is there this dependent behaviour. It is much more than the sum of individual elements and increases exponentially.

[sdatkinson]

• buffer size all

Which buffer sizes in specific did you try?

[emkayg]

256 and 512 is where unusually work. May have tried 1024 but that’s often impractical. I can check again though and run through the tests methodically with buffer size as a variable. Unfortunately I’ve had to revert to an older NAM version (that has some other issues) to get some mixes done for deadlines, but I can check on this as soon as those are done.

[sdatkinson]

Thanks. I'm interested to hear about lower buffer sizes as well (128, 64, 32)

[CronosBeyond]

I observed the same behavior but was not able to point it down specifically to what you described here. The more instances of NAM plugins I use (in Cubase), the more CPU consumption I see for an armed track. Makes sense when the project is playing but not when it's silent.

I also see an increase of CPU load the longer the project is open. But only when I use NAM. Restarting the project an open it again restarts the cycle until the CPU is at its limit and if have to restart the project again.

[emkayg]

Yes. I too experience a sort of “cpu useage leak” as well where a session reload seems to solve it temporarily. Though I have not been able to track down a specific behaviour for this quite yet. This particular issue though seems to be more significant (at least for me ever since I discovered it), which is why I’m focusing on that aspect in this post. Should be able to test lower buffer settings by the weekend if no one else gets to it.

[CronosBeyond]

Thanks. I'm interested to hear about lower buffer sizes as well (128, 64, 32)

I did some tests with more buffer sizes, hope that helps @sdatkinson .
32 is not possible on my device, 48 is the lowest.

Computer & other info

---

Windows 11
AMD Ryzen 7950X (16 cores)
Plugin version 0.7.13 (VST3)
Cubase 14 (ASIO Guard turned OFF)
RME ASIO (Fireface 802)
Sample rate 48.0 kHz

Hint: load is shown as Cubase real time load. Not CPU load measured via e.g. Process Explorer.

Results

---

Buffer size: 512

• 1 instance of NAM, 1 instance armed: ~9%
• 20 instances of NAM, 1 instance armed: ~24%

Buffer size: 128

• 1 instance of NAM, 1 instance armed: ~12%
• 20 instances of NAM, 1 instance armed: ~22% (lower than with buffer size 512, tested several times)

Buffer size: 64

• 1 instance of NAM, 1 instance armed: ~15%
• 20 instances of NAM, 1 instance armed: ~25%

Buffer size: 48

• 1 instance of NAM, 1 instance armed: ~18%
• 20 instances of NAM, 1 instance armed: ~28%