WebAudio and autoplay restrictions

[youennf]

Autoplay restriction rules are more and more controlling whether an AudioContext can be started or not. Typically, it now requires a user gesture.

In WebRTC land, as can be seen in https://bugs.webkit.org/show_bug.cgi?id=180522, WebAudio is usually used only for analysis. But autoplay restrictions are still kicking in.
In WebKit, autoplay restrictions are disabled if getUserMedia capture is on.

If we had something like an analysis-only audio context, it could probably start without being tied to any user gesture. Additionally, since it would not be tied to hardware rendering, it could run in lower priority threads.

[rtoy]

From today's WG teleconf, we agreed that we need some clarification here.

The referenced bug seems to want an audio context to be allowed to play if there's no audio output. We agreed that that is not really possible because the graph can be changed dynamically at any time and suddenly connecting some source to the output.

I think an analysis-only context is not something we wish to do now; it would be the next version at the earliest.

[mdjp]

Add 1 field to audioContext options dictionary. Audible/Muted/Analysis only.

[padenot]

This is tracked in https://github.com/w3c/autoplay/. We're closing this, because the work is going to happen there and not here: no changes is going to be made to any Web Audio API interface.