[w3ctag/design-reviews] Web Audio AudioContext "interrupted" state (Issue #1069)

gabrielsanbrito created an issue (w3ctag/design-reviews#1069)

こんにちは TAG-さん!

I'm requesting a TAG review of AudioContext "interrupted" state.

The [Web Audio API](https://webaudio.github.io/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 ](https://webaudio.github.io/web-audio-api/#AudioContext)interface, which represents an audio graph. An AudioContext can find itself in one of three states: ["suspended"](https://webaudio.github.io/web-audio-api/#dom-audiocontextstate-suspended), ["running"](https://webaudio.github.io/web-audio-api/#dom-audiocontextstate-running), or ["closed"](https://webaudio.github.io/web-audio-api/#dom-audiocontextstate-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()](https://webaudio.github.io/web-audio-api/#dom-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](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/IframeMediaPause/iframe_media_pausing.md), the proposed [Audio Session API](https://w3c.github.io/audio-session/), 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](https://webaudio.github.io/web-audio-api/#enumdef-audiocontextstate) enum.

  - Explainer: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/AudioContextInterruptedState/explainer.md
  - Specification: https://webaudio.github.io/web-audio-api/#dom-audiocontextstate-interrupted 
  - WPT Tests: None
  - User research: None
  - Security and Privacy self-review: we have addressed concerns related to [question 2.2 ](https://www.w3.org/TR/security-privacy-questionnaire/#minimum-data) during discussions in the WG and have limited the situations where the transition `"suspended" -> "interrupted"` should happen.
  - GitHub repo: https://github.com/WebAudio/web-audio-api/issues/2392
  - Primary contacts:
      - @hoch, Google, editor
      - @padenot, Mozilla, editor
      - @gabrielsanbrito, Microsoft, writer
  - Organization/project driving the specification: Microsoft
  - Multi-stakeholder support³:
    - Chromium comments: positive
    - Mozilla comments: https://github.com/mozilla/standards-positions/issues/1083
    - WebKit comments: https://github.com/WebKit/standards-positions/issues/410
  - Status/issue trackers for implementations: https://chromestatus.com/feature/5172068166139904

Further details:

  - [X] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/)
  - Previous early design review, if any: https://github.com/w3ctag/design-reviews/issues/####
  - Relevant time constraints or deadlines:
  - The group where the work on this specification is currently being done: [Audio Working Group](https://www.w3.org/groups/wg/audio/)
  - 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](https://webaudio.github.io/web-audio-api/#dom-audiocontextstate-interrupted). Regardless, we would like TAG to do a horizontal review on the "interrupted" state feature.

Thank you!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1069
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1069@github.com>

Received on Monday, 17 March 2025 22:16:13 UTC