Profiling Web Audio apps in Chrome

Debugging glitchy Web Audio: profiling with tracing and Audion

Unexpected audio glitches—popping noises, dropouts, silence—are a common headache when building Web Audio apps. The root cause can live in your own code, in the browser's rendering engine, or in the OS audio stack. Chrome offers two complementary tools to help you find it: about://tracing for deep performance analysis and the Audion DevTools extension for real-time graph and renderer inspection.

When to use which tool

about://tracing is the tool of choice when you're chasing unexplained audio dropouts. It records fine-grained thread activity, showing you time slices spent in specific function calls and the exact timing of audio callbacks on each thread. This makes missed render deadlines and heavy garbage collection visible. Chromium engineers will often ask for tracing data when you file a bug, especially if they can't reproduce the issue locally.

The Audion extension fills a different need: visualizing the otherwise opaque AudioNode graph and monitoring the audio renderer's live performance. If your graph has grown complex and a change results in silence, Audion shows you the topology so you can reason about what broke. Its render capacity meter shows how close the renderer is to exhausting its time budget—if that number approaches 100 percent, glitches are likely.

Capturing tracing data

For a clean trace, close other tabs and windows and disable extensions, or start a fresh Chrome instance. Then:

1. Open your app in one tab.
2. In another tab, navigate to about://tracing.
3. Press Record and choose Manually select settings.
4. Set both Record Categories and Disabled by Default Categories to None.
5. In Record Categories, enable:
   • audio
   • blink_gc
   • media
   • v8.execute (for AudioWorklet JS performance)
   • webaudio
6. In Disabled by Default Categories, enable:
   • audio-worklet (to see where the AudioWorklet thread starts)
   • webaudio.audionode (for per-AudioNode trace detail)
7. Start recording, reproduce the glitch in your app tab, then stop and save the trace.

Reading the trace

Chrome's Web Audio engine renders audio in one of two modes, each with a distinct threading pattern. In operating system mode, an AudioOutputDevice thread—a real-time priority thread from the browser's audio service—runs all Web Audio code. Irregular spacing in this lane indicates jittery device callback timing, a known problem with Linux and Pulse Audio (see Chromium issues #825823 and #864463).

In worklet mode, there's a thread jump from AudioOutputDevice to an AudioWorklet thread, which is not real-time priority. All Web Audio operations run there once the worklet is active. Look for well-aligned traces across both lanes; irregularities usually appear as a large garbage-collection block or a missed render deadline.

Ideal traces in either mode show audio device callback invocations evenly spaced and render tasks completing well within their budget.

Real-world trace patterns

Render tasks exceed the budget

In this example from Chromium issue #796330, callback timing is steady but the AudioWorkletProcessor code takes too long and spills past the render deadline.

What to try:

• Reduce the number of AudioNode instances in the graph.
• Optimize the code running inside AudioWorkletProcessor.
• Increase AudioContext base latency.

Garbage collection blocks the worklet thread

Garbage collection is managed on the worklet thread, unlike the OS audio thread. Code that allocates memory (for example, creating new arrays) will trigger collection that synchronously blocks rendering—if the combined work exceeds the render budget, you'll hear glitches.

What to try:

• Allocate memory once and reuse buffers.
• Consider patterns built on SharedArrayBuffer, as used by several production Web Audio apps. The Audio Worklet Design Pattern article covers this approach, though it's not a perfect fix.

Jittery AudioOutputDevice callbacks

Audio callback timing should be the most precise clock in the system. If the OS audio subsystem can't deliver a solid cadence, everything downstream suffers. Compare this trace's callback intervals to the previous two examples—the spacing varies visibly.

What to try:

• Increase the system callback buffer size via the latencyHint context option.
• File an issue on crbug.com and attach the tracing data.

Inspecting graphs live with Audion

The Audion extension, available from the Chrome Web Store, adds a Web Audio panel to DevTools.

The panel is split into four parts: a context selector, a property inspector, a graph visualizer, and a performance monitor.

Context selector

Pages can host multiple BaseAudioContext objects. This dropdown picks which one to inspect. A trash-can icon also lets you trigger garbage collection manually.

Graph visualizer and property inspector

The visualizer renders the selected context's live graph topology, updating in real time. Click any node to see its properties in the side panel. Dynamic values in AudioParam are not inspectable.

Performance monitor

Active only when the selected context is an AudioContext running in real time, the bottom status bar refreshes every second with two metrics:

• Callback interval (ms): A weighted mean and variance. The mean should be stable and the variance near zero; a large variance points to unstable system-level callback timing.
• Render capacity (percent): Approaching 100 percent means the renderer is nearly out of budget—reduce the graph's workload, such as by removing AudioNodes.

The legacy WebAudio DevTools panel is still available under More tools in the DevTools menu, but the extension is now the recommended path.

Debugging Web Audio is difficult, but these tools make the renderer's behavior observable. If you find a problem in Chrome itself, file it on crbug.com; issues with the extension go to its tracker.