Performance meter

The performance meter shows how much of each audio block’s time the engine spends making sound. Turn it on with View → Performance meter and a small readout appears in the header with the average load and a peak marker. Click it for the details: average and peak load, late blocks, how often the output buffer ran dry and how far ahead the engine is reading. It is a measurement of the audio callback, not of your computer as a whole.

When to use it

Open it when playback crackles or a part stutters and you want to know whether the engine is the reason. Watch it while adding a dense instrument or a chain of oversampled effects to see what each one costs. It is also the honest way to judge an older laptop or tablet: a section that sits near the top of the meter is a candidate for freezing.

Controls

The header readout

The number is a one-second average of engine load; the marker is the two-second peak. The readout updates a few times a second and clears when playback stops, keeping the last counts for you to read.

The details

Average and peak are percentages of the time each block is allowed to take. Late blocks counts blocks that took longer than their budget. Buffer ran dry counts the moments the browser asked for audio that was not ready, which is the figure closest to an audible dropout. Read-ahead shows how far ahead of the output the engine is working. Playback starts reset the counters.

What it measures

The timing covers the rendering of instruments, effects and the output safety check inside the audio thread. Editor work, waveform drawing and the messages between threads are outside it. A late block is a warning, not proof of a dropout; the browser may have had slack to absorb it. On browsers without a precise clock the meter uses a coarser one and allows a millisecond of uncertainty before counting an overrun, and the popover says so.

Where it works

Both workspaces report load: multitrack playback, single-file playback, note audition and live input monitoring. The preference is saved in this browser and starts off.

Tips

• You do not need the meter to know when a song is too heavy. When the engine stays over its real-time budget for a few seconds of playback, the studio says once per song, “This song needs more than this computer can play in real time. Freezing some tracks will help.” See Track freezing.
• Judge load on a production build at the sample rate you actually use; a development server or an attached debugger makes everything look slower than it is.
• Compare peaks rather than averages when hunting a stutter. A part that averages 30 percent but peaks at 100 on every chord change is the one to freeze.
• Late blocks that appear only at the first bar are the engine warming up; see Playback.