v136 · multimedia

AudioContext Interrupted State

The current Web Audio API lacks a mechanism for the User Agent (UA) to interrupt playback for scenarios such as exclusive audio access (VoIP) or when a laptop lid is closed. To address this, we propose adding an "interrupted" state to AudioContextState. This new state would allow the UA to pause playback in these scenarios and enable web applications to resp

concepts

  1. interrupted State

    AudioContext gains an interrupted state for OS-level audio interruptions (phone calls, focus loss). Sites can surface 'paused by system' UX cleanly.

  2. VoIP-style pause & resume

    Live Web Audio tone player: distinguishes interrupted (OS pulled focus — "paused by system") from suspended (user paused), with optional auto-resume strategy when focus returns.

  3. State Machine Visualiser

    The full set of AudioContextState transitions on one screen: suspended ↔ running ↔ interrupted plus the terminal closed. Buttons drive each legal call, the diagram lights up the active node, and every statechange is timestamped.

  4. Screen share coordinator

    A simulated recording app that responds to the interrupted state correctly: stops recording, shows "interrupted by system" banner, auto-resumes when focus returns — and distinguishes that from a user-triggered suspended which should NOT auto-resume.

why it shipped

Currently, there is no way for the User Agent (UA) to interrupt a Web Audio API AudioContext playback on its own - i.e., the suspension must happen in response to a user action. There are scenarios where the UA must be able to interrupt audio playback on its own: - Interrupt an AudioContext when another application requires exclusive access to audio hardware; - Audio Session API (https://w3c.github.io/audio-session/) - "media-playback-while-not-visible" permission policy (https://chromestatus.com/feature/5082950457884672)

references