I'm requesting a TAG review of AudioContext "interrupted" state.
The Web Audio API is widely used to add advanced audio capabilities to web applications, like web-based games and music applications. One of the API's features is the AudioContext interface, which represents an audio graph. An AudioContext can find itself in one of three states: "suspended", "running", or "closed". Once an AudioContext is in the "running" state, it can only pause media playback by transitioning to the "suspended" state when, and only when, user code calls AudioContext.suspend() on this AudioContext. However, there are situations where we might want to let the User Agent (UA) decide when to interrupt playback - e.g., the proposed "media-playback-while-not-visible" permission policy, the proposed Audio Session API, or during a phone call where the calling application will need exclusive access to the audio hardware. To support these scenarios, we propose adding a new "interrupted" state to the AudioContextState enum.
Security and Privacy self-review: we have addressed concerns related to question 2.2 during discussions in the WG and have limited the situations where the transition "suspended" -> "interrupted" should happen.
The group where the work on this specification is currently being done: Audio Working Group
The group where standardization of this work is intended to be done (if different from the current group):
Major unresolved issues with or opposition to this specification:
This work is being funded by: Microsoft
You should also know that...
This specification has already reached consensus in Audio WG and has been merged to the Web Audio specification. Regardless, we would like TAG to do a horizontal review on the "interrupted" state feature.
OpenedMar 17, 2025
こんにちは TAG-さん!
I'm requesting a TAG review of AudioContext "interrupted" state.
The Web Audio API is widely used to add advanced audio capabilities to web applications, like web-based games and music applications. One of the API's features is the AudioContext interface, which represents an audio graph. An AudioContext can find itself in one of three states: "suspended", "running", or "closed". Once an AudioContext is in the "running" state, it can only pause media playback by transitioning to the "suspended" state when, and only when, user code calls AudioContext.suspend() on this AudioContext. However, there are situations where we might want to let the User Agent (UA) decide when to interrupt playback - e.g., the proposed "media-playback-while-not-visible" permission policy, the proposed Audio Session API, or during a phone call where the calling application will need exclusive access to the audio hardware. To support these scenarios, we propose adding a new "interrupted" state to the AudioContextState enum.
"suspended" -> "interrupted"
should happen.Further details:
You should also know that...
This specification has already reached consensus in Audio WG and has been merged to the Web Audio specification. Regardless, we would like TAG to do a horizontal review on the "interrupted" state feature.
Thank you!