Intent to Prototype: AudioContext Interrupted State

[Chromestatus]

Contact emails

gabrie...@microsoft.com, ste...@microsoft.com

Explainer

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AudioContextInterruptedState/explainer.md

Specification

None

Summary

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 respond appropriately. 

Blink component

Blink>WebAudio

Motivation

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)

Initial public proposal

https://github.com/WebAudio/web-audio-api/issues/2392

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

When AudioContext.resume() is called for an AudioContext in the "closed" state, the returned promise is rejected. With this proposal, the same behavior will also happen when AudioContext.resume() is called while the AudioContext "interrupted". In this case, a web page that is not aware of the existence of the "interrupted" state might imply that the AudioContext has been closed. In this situation, application shouldn't rely solely on the returned promise resolution outcome and also check the AudioContext state.

Gecko: No signal

WebKit: In development (https://github.com/WebKit/standards-positions/issues/410) Safari is supportive and already has a prototype implemented to support the Audio Session API.

Web developers: Positive (https://github.com/whatwg/html/issues/10208) Even though this feature has not been explicitly asked by web developers, it is required to make other browser APIs to work properly with Web Audio - e.g. media-playback-while-not-visible permission policy and the Audio Session API.

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

None

Finch feature name

AudioContextInterruptedState

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/374805121

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5172068166139904?gate=5177003167449088

This intent message was generated by Chrome Platform Status.