Modern browsers (Chrome 71+, Safari, Firefox) implement autoplay policy to prevent unwanted audio playback. Any new AudioContext is created in the suspended state and requires a user gesture (click, tap, keypress) to resume(). This is by design — it protects users from autoplaying audio and reduces data usage. Always call audioContext.resume() inside a user event handler.

The best practice is to create the AudioContext on user interaction:

let audioCtx;
document.addEventListener('click', () => {
  audioCtx = new AudioContext();
  // Now it will be 'running'
}, { once: true });

Alternatively, create it early and call resume() inside a click/touch handler. Use navigator.userActivation.hasBeenActive (Chrome 72+) to check if the user has interacted with the page.

suspended — Context is created but not processing audio. Occurs on creation (autoplay policy) or after suspend().
running — Audio is actively being processed. The normal operational state.
closed — Context is permanently destroyed. Cannot be resumed. You must create a new AudioContext. This happens after calling close(). Always check audioContext.state before using it.

suspend() — Pauses audio processing temporarily. The context can be resume()'d later. All nodes and connections are preserved. Good for pausing audio when the tab is hidden.

close() — Permanently destroys the AudioContext. All resources are released. You cannot resume a closed context — you must create a new one. Use this when you're completely done with audio to free system resources.

Use this pattern:

const ctx = new AudioContext();
if (ctx.state === 'suspended') {
  console.log('Autoplay likely blocked');
  // Show a "Click to enable audio" button
  document.body.addEventListener('click', () => ctx.resume(), { once: true });
}

Also check navigator.userActivation?.hasBeenActive in modern Chrome. If it's false and your context is suspended, autoplay policy is the reason.

Browsers may throttle or suspend AudioContext processing when the page is hidden to save CPU and battery. Listen for the visibilitychange event and call suspend() when hidden and resume() when visible. For critical audio (e.g., music players), consider using a Service Worker with the Media Session API, though this has limitations.

Technically yes, but it's strongly discouraged. Most browsers limit the number of concurrent AudioContexts (typically ~6 on desktop, fewer on mobile). Each context consumes significant system resources. Instead, use a single shared AudioContext and create separate gain/analyser sub-graphs for different audio sources. If you need isolation, consider using OfflineAudioContext for rendering.