Add resume and interrupt events on the MediaSession object

[mounirlamouri]

Ideally, we should allow MediaSession instances decide how to behave when they are resumed or interrupted. Exposing events that could be cancelled would help. This is particularly important for Web Audio for which the best a UA can do is to break the link between the producing source and the output device. A MediaSession instance might stop the producing source and resume it when needed.

In addition, the interrupt event could have information about the ducking behaviour.

Both events could have information regarding how and why the session was resumed/interrupted. For example, whether it happened from a user interaction.

[foolip]

Yep, I agree that we should fire events for these state transitions. However, it does make it necessary to deal with the situation where a session is interrupted and in response the script does something weird like playing something else or calls preventDefault() without actually stopping playback itself. There's some relevant platform differences here. Android will happily let this kind of situation happen, while it looks like iOS will just mute the app but let it think that it's getting its way. Does that sounds right, @doomdavve?

[doomdavve]

Yes, the difference seems to be that on iOS apps can be muted by the system as dictated by the currently now playing app.

[mounirlamouri]

How detectable is that for the web page? Can we leave a door for the UA to ignore .preventDefault()? If my website is correctly written and I stop my audio processing and streams when the interrupt event is received and call preventDefault(), would the behaviour be any different between iOS and Android?

[foolip]

There is no issue for code that we would deem correct, all we have to contend with is accidental failure to pause primarily, deliberate abuse of such a difference seems less worrying, to me at least.

The way I see this, we ought to have a default behavior that pauses all participating media elements and mutes/suspends all participating audio contexts. So it comes down to whether or not the event is cancelable. I lean towards saying that at least the interrupt even should be non-cancelable, unless we can see some plausible use case that would justify the resulting incompatibility.

[xxyzzzq]

Closing this issue since we are moving audio focus out to a separate API.

[xxyzzzq]

This issue was moved to WICG/audio-focus#22