Performance

This article explains what affects performance in AudioNodes, and gives you some tips to monitor and improve it in your projects.

Performance Overview

As with all digital audio workstations, you’ll eventually run into a performance ceiling as you keep adding increasingly complex logic into your project. This is especially easy to do in AudioNodes, because everything is modular, with a lot of feedback.

When you run into the performance ceiling, buffer underrun occurs, causing audible glitching. It’s when you hear your audio output to be crackling and stuttering.

Performance in AudioNodes depends on 2 factors:

  • Nodes you use, and your patch in general — the more Nodes you use (or more complex Nodes you use), the worse performance gets
  • Your machine — the faster your machine, the more Nodes you can use before performance degrades

Performance Optimization Tips

An important rule of thumb with optimization is measuring results. To help you with that, AudioNodes has a processing load meter, shown at the top as a percentage (see the Processing Load % section below). Keep an eye on its value to see how your project is performing after a specific change.

The rest of this section gives you some tips to reduce your processing load.

Leverage Constant Folding

AudioNodes has an automatic optimization process called Constant Folding, which enables several Nodes to run in constant mode. A Node running in constant mode has zero performance impact, and can be used in large numbers without any performance problems whatsoever.

While you don’t have to do anything for it to work, some patches work better for constant folding, some don’t. Check out the article to learn how you can maximize its impact to improve performance.

Avoid Expensive Nodes

Different Nodes can have wildly different performance characteristics. A Gain Node, for example, is basically free and even several thousand won’t make a real dent in performance.

On the other hand, the following Nodes, for example, are particularly expensive:

  • Pitch Shift Node — large resolution settings are very expensive
  • Poly Subpatch Node — a large number of voices can get expensive fast, especially if the internal patch is complex
  • Convolver Node — a large room setting with a high reflection %, or an otherwise long impulse response is expensive

If you can, minimize the usage of expensive Nodes, or use a cheaper configuration setup for them. A few tips as a rule of thumb with Nodes:

  • Each Node has a performance impact on its own. That is, 2 Convolver Nodes with the same configuration have 2x as much performance impact as 1. Try to first mix your audio together, and then use a single Convolver Node at the end, if possible.
  • You can easily delete multiple Nodes and then undo the deletion (as long as you keep AudioNodes open). This is a quick and easy way to identify which part of your patch is causing the most load. Keep an eye on whether processing load drops significantly after deleting some Nodes, or not.
Close Other Apps & Tabs

This probably goes without saying, and is probably the first thing you find in those low quality AI generated articles on the web, but your machine shares your available CPU capacity between what you have open (including processes running in the background).

Those other processes can take up CPU cycles, and ultimately cause AudioNodes to run out of processing capacity earlier than what your machine could otherwise handle. Thus, it’s a good idea to close them if you run into performance issues. Same goes for browser tabs.

Split Projects

As a last resort, you can separate your project into multiple projects, export them each into an audio file, and then reopen them using an Audio File Node each. Audio file playback is very cheap, typically causing the same processing load as a single Oscillator Node. This technically enables you to scale your projects indefinitely, but:

  • Is increasingly cumbersome to do as you have more projects
  • Does not support real-time input, like the MIDI Keyboard Node

Still, it’s a possible solution if everything else fails.

Processing Load %

Beginning with update 0.9.11, AudioNodes displays a processing load monitor in the header. This is a percentage value displaying how much real-time processing power your current project is using:

Current processing load — 39% — shown at the top

The lower the number, the better:

  • 0% means AudioNodes is basically idle
  • 40-60% means AudioNodes is using half of what your machine can do, and has some more headroom for additional Nodes still — this is a safe, optimal load, where you are using enough of your machine’s capabilities, but you are typically safe from glitching
  • 80% (or up) means you are very close to your machine’s limits; in practice, glitching is imminent at these levels (with varying frequency) — at this load level, you’ll typically want to look into optimizing your project
  • 100% means your machine is working at capacity, and is unable to process your project; audio is skipped and audible glitching occurs — at this level, you need to optimize your project somehow
How Load is Calculated

The processing load is based on the time it takes to process a block of samples on your machine, not CPU usage. As a result, it’s a very accurate estimate of how much processing load you are using, and a very reliable estimate of whether you are close to glitching or not. It’s basically a time-averaged value of the following equation:

time_per_sample / max_time_per_sample

Or time_per_sample divided by max_time_per_sample, where, simplified down:

  • time_per_sample is the time it takes for your system to process a single output sample, in seconds
  • max_time_per_sample is the available time for a sample to be processed before you’d hear glitching, again in seconds
    • At a sample rate of 48kHz (meaning AudioNodes processes 48_000 output samples per second), this value is 0.020833 milliseconds, which may sound like a very low value, but computers are good at these sorts of things (as long as your project is performant enough, that is)

The higher the project complexity, the higher the time_per_sample value, and the higher the sample rate, the lower the max_time_per_sample value. This is the mathematical theory behind why reducing project complexity will help you avoid glitching.

Processing Load Meter Pitfalls

While the processing load meter should be pretty accurate, there is one thing to keep in mind. Orphaned Nodes (or Nodes not ultimately connected to an Audio Destination Node) that just output into nothing are not always correctly measured.

As a result, with a project with a lot of Nodes not connecting to anything, the meter may display a lower-than-actual processing load.

Performance When Exporting Projects

Performance when exporting projects is secondary, because it’s not a real-time process, and a high processing load won’t cause glitching. In a way, you can say that the export process is always using a 100% processing load, and is speeding up or slowing down accordingly.

However, the more expensive your project, the longer it will take for the export process to complete. This is typically closely correlated to real-time processing load: a project with a 50% processing load will take roughly twice as long to export as a project with a 25% processing load (assuming they have the same duration, and you use the same export settings).