I measured the differences in latency and CPU usage due to Web Audio processing units, since renderSizeHint was added in Chrome 153

Introduction

When building instruments, operation sounds, or real-time effects in the browser, there are many cases where you want to minimize latency in response to user input. However, latency involves multiple layers of processing across the browser, OS, and audio hardware. Questions arise that are hard to answer from the spec alone — such as how much difference reducing the browser's internal processing unit actually makes at the physical input/output level, or how much CPU usage changes.

In today's environment, specifying 64 frames resulted in a physical loopback round-trip latency approximately 2.90 ms shorter than 128 frames. CPU usage at idle was slightly higher with 64 frames, meaning that smaller values are not unconditionally better. This article uses a Mac and a common USB audio interface to compare round-trip latency and CPU usage for different processing unit sizes, and from those results considers which of 64, default, or hardware to try first.

What is renderSizeHint

Web Audio processes audio by grouping it into a fixed number of frames. This group is called a render quantum, and the number of frames is called the render quantum size.

In Chrome 153, renderSizeHint was added, allowing you to request a render quantum size when creating an AudioContext. In addition to integers, you can specify default to use the default 128 frames, or hardware to let the browser choose a value based on the current configuration. Note that renderSizeHint is a hint, not a guarantee that the requested value will be adopted. The actual adopted value can be confirmed via renderQuantumSize on the AudioContext.

In this article, we used this to change the render quantum size and measured how the physical loopback round-trip latency and CPU usage change.

Test Environment

• macOS 26.6.2
• Apple M4
• Google Chrome 153.0.8010.37
• RME Babyface Pro FS

Target Audience

• Those who want to shorten the response of instruments or operation sounds in Web Audio on macOS
• Those who want to understand the relationship between renderSizeHint values and latency or CPU usage
• Those who want to know how to measure using a USB audio interface

References

• Chrome 153 Release Notes
• Web Audio API 1.1 Editor's Draft

Methodology

First, we confirmed the value passed to renderSizeHint and the value actually adopted.

const context = new AudioContext({
  renderSizeHint: 64,
});

await context.resume();

console.log({
  requested: 64,
  actual: context.renderQuantumSize,
});

The console output was as follows.

{ requested: 64, actual: 64 }

In this environment, we confirmed that the specified 64 frames was adopted as-is.

Next, we measured round-trip latency. We created a test page, output a 5-second signal, and routed it back to the input of the same audio interface via cable.

The idle condition performs only signal output and input recording, with no additional computation for comparing CPU usage. The heavy synthesis load condition includes repeated Math.sin calculations.

The signal contains 10 known markers at 0.5-second intervals. Each marker is detected from the recorded input signal using normalized cross-correlation, and the median of the differences between the positions in the output signal and the detected positions in the input signal is taken as the round-trip latency.

Four types — 64, 128, 256, and hardware — were each measured 3 times under both idle and heavy synthesis load conditions. (hardware: the specification that lets the browser choose the render quantum size.) For the heavy synthesis load, 100,000 iterations per 128-frame processing cycle was used as the baseline, and the number of iterations per cycle was scaled proportionally to the actual processing unit size. This ensures that the target computation amount per second remains roughly the same regardless of the processing unit.

CPU values are the usage rates for the Chrome renderer process handling the test page, measured over the same interval including the 5-second signal processing and the periods before and after it. One core is treated as 100%, and the average of 3 measurements per condition was used.

Results

The main results are as follows.

The aggregated values from 3 measurements per condition are as follows.

Findings

In this environment, integer specifications of 64, 128, and 256 were reflected in the actual render quantum size. The value chosen by the browser was also retrievable when using hardware. It was confirmed that the specified value and the adopted value can be checked separately.

For the same input/output path, conditions with smaller processing units resulted in shorter physical loopback round-trip latency. In ascending order of latency: 64, 128, and 256 frames.

As the render quantum size increased from 64 to 128 to 256 frames, idle CPU usage decreased. Under heavy synthesis load, no clear increase or decrease in CPU usage corresponding to the processing unit size was observed.

Discussion

I believe the reason why the time difference of the processing unit alone cannot explain the difference in round-trip latency is that the round-trip path includes Web Audio, processing between Chrome and macOS, output, the analog path, and input. Also, the higher CPU usage at idle for smaller processing units is likely due to the increased number of AudioWorklet calls. In actual applications, it seems advisable to check not only average values but also AudioWorklet processing time and audio state.

For instruments or real-time effects where latency is the priority, 64 seems like a good first candidate. Whether the difference observed here is worth the trade-off in processing headroom will need to be judged on a per-application basis.

If you want to maintain the traditional default, omitting renderSizeHint or specifying default is the clearest approach. If there is a specific reason to explicitly request 128 frames, then the integer 128 would be the candidate. In either case, it seems advisable not to rely solely on the specified value and to verify with renderQuantumSize.

Summary

For renderSizeHint in Chrome 153, we confirmed the adopted values, round-trip latency, and CPU usage when specifying 64, 128, 256, and hardware. Since renderSizeHint is a hint, implementations need to use the value actually adopted in renderQuantumSize. It seems best to first select a candidate from 64, default, or hardware according to the use case, and then verify the adopted renderQuantumSize value and actual processing headroom on the target device. We hope this article serves as useful information when choosing a processing unit size for Web Audio.