Should we allow linking AudioSessions to each HTMLMediaElement/AudioContext object?

[youennf]

Is it useful to set a particular AudioSession to a particular HTMLMediaElement/AudioContext?

[jernoble]

I think it is. A site may have both alert sounds ("transient") and a music stream ("playback"). It would be convenient to allow alert sounds to duck playback the same way a system alert sound would, without requiring the page to "re-invent the wheel" and implement ducking manually.

[jernoble]

The most straightforward API design would involve monkey-patching HTML to add a .audioSession property on HTMLMediaElement and AudioContext. I don't know how this would work for navigator.mediaDevices.getUserMedia() however. Maybe navigator.mediaDevices.getUserMedia({audio: { audioSession: captureSession }})?

[jernoble]

Alternatively, the MediaStream returned by getUserMedia() could have a .audioSession property. But we'd need a the MediaStream to start out deactivated.

[youennf]

Right, this would require such setters/getters, plus AudioSession constructor, plus requestFocus/releaseFocus.
This seems potentially useful as a second step.

[youennf]

For instance

partial interface AudioSession {
  constructor();

  // Request audio focus from the platform. Resolves with true if the request was successful.
  Promise<bool> request();

  // Abandons audio focus. Rejects with an error if the session does not have audio focus.
  Promise<void> abandon();
};

[tguilbert-google]

A site may have both alert sounds ("transient") and a music stream ("playback").

+1 one to this question/issue/answer. I support adding a way to allow transient sounds from sites with longer playback.

[youennf]

Tentative TPAC 2024 proposal: add the following abilities in the roadmap, and discuss whether V1 or not:

• Allow setting AudioSession on HTMLMediaElement and AudioContext (maybe getUserMedia and getDisplayMedia in the future).
• AudioSession constructor
• AudioSession focus API