Improve Playback Performance

Measure the same demanding section before and after each change. Keep the audio device, sample rate and block size fixed while comparing.

Read audio load during playback

In a live session, start the piece, let it reach the section you want to test, then evaluate:

let cpu = audio_cpu_load();
print(cpu);

load is smoothed audio callback load, and peak is its recent peak. A value of 1 means the callback used its whole available time. This is audio deadline usage, not the operating system’s process CPU percentage. Leave margin for the loudest or busiest part of the piece.

Compare multicore rendering

Save the source and plugin state, then compare fresh servers from the project directory:

resonon --multicore=false server

Stop that server before starting the alternative:

resonon --multicore=true server

Reconnect VSCode, evaluate the same piece and measure the same section. Check for inherited RESONON_PARALLEL in your shell: it overrides the flag. Keep the mode that gives this piece more reliable playback. Small sessions may gain nothing from multicore rendering.

Reduce work and measure again

Simplify the busiest instrument or effect chain one change at a time. For a common reverb, try sharing an effect with a send if that gives the sound you want. For visuals, reduce screen.set_quality() and compare again.

If the live device still misses deadlines, try a larger supported [audio] buffer_size in preferences and apply it with reload_preferences() while no take is recording. Expect more monitoring latency; inspect audio_latency() after the change. See Fix Audio Problems for device checks and Command Line for the flags.