Contact emails gabrielbr...@microsoft.com, stev...@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 - ie, 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 - eg 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. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/671b2737.2b0a0220.32f303.0361.GAE%40google.com.
