Skip to content

How to Use

Chi Zeng edited this page Mar 25, 2017 · 8 revisions

Install Web Audio Inspector at its Chrome Web Store page.

Navigate the graph

To view the graph,

  1. Enable Web Audio Inspector at chrome://extensions if it is disabled.
  2. Open Chrome Developer Tools.
  3. Visit a page with web audio activity. If the page is visited before opening developer tools, Web Audio Inspector may require a page refresh due to missing web audio updates.
  4. View the Web Audio panel.

Pan and zoom the graph with the mouse and wheel. Click the reset button to fit the graph within the panel.

Reset button

AudioNodes are categorized by color based on their purposes.

Inspect nodes

To view the properties (AudioParams, mutable and immutable fields, and information on buffers if applicable), of an AudioNode, click it. The node will gain an orange outline, and a pane will open that details the AudioNode.

Inspect an AudioNode.

To obtain a JavaScript reference to an AudioNode in the console of developer tools, pass the displayed numeric ID of the AudioNode to the global __node__ function (added by Web Audio Inspector). For instance, in the above graph, we obtain a reference to the currently inspected BiquadFilterNode with __node__(7). Afterwards, of course, one could use the Web Audio API to modify the graph.

Web Audio Inspector adds a __resource_id__ property to each AudioNode. This property is its numeric ID displayed in the visualization.

Caveats

Disable while benchmarking

When benchmarking an app (for latency), disable Web Audio Inspector. Its code for issuing messages on web audio updates adds overhead.

No AudioNodes are garbage-collected

Web Audio Inspector keeps references to all AudioNodes created in order to allow the user to obtain references to the nodes (via the __node__ method). AudioNodes hence do not get GC-ed until the user leaves the web page. Sometimes, this behavior may unfortunately produce tall graphs.

Tall graph

Nonetheless, being able to examine the audio graph is sometimes worth this downside.

Data on properties may be stale at breakpoints

Data displayed in the pane might become out of date if the main UI thread stops (at say a breakpoint). The visualization relies on messages issued in the main thread on web audio updates. When the main thread halts, these messages are not issued.

For example, to be concrete, the code may call linearRampToValueAtTime on an AudioParam right before a breakpoint. After breaking, no new messages will be issued on property updates (until the debugger continues again), yet the AudioParam will proceed to ramp to its target value. For similar reasons, at a breakpoint, the pane might simply not show because the extension cannot receive any data on properties.

That being said, connections within the graph (the graph structure) should remain correct because the main thread cannot execute any calls to connect or disconnect at a breakpoint.

Making the debugger continue execution will prompt the pane to become back up to date.