Summary: AudioContexts are very useful objects, but they use quite a lot of CPU time (they use a very high priority thread that wakes up often to compute and output audio), keep the audio hardware awake and in low latency mode. In other words, authors should try to dispose of their AudioContext when they don't need them. This has been the cause of multiple B2G battery life regression, as the Dialer app uses an AudioContext to output the DTMF tones.
This API allow authors to simply `suspend()` the processing for an already existing Web Audio API graph, effectively "freezing" all time and processing. The high priority thread stops, the audio hardware can go to sleep. When needed again, a call to `resume()` start the processing again. `close()` tells the graph to close its audio output, to release the underlying platform audio stream as fast as possible. This is important because some platforms have a strict and low limit on the number of AudioContext that can simultaneously exist. Since those are inherently asynchronous operation (platform audio APIs can take some time to stop/start, etc.), Promises are returned to notify content that the operation has finished. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1094764 Link to standard: http://webaudio.github.io/web-audio-api/#widl-AudioContext-suspend-Promise-void http://webaudio.github.io/web-audio-api/#widl-AudioContext-close-Promise-void http://webaudio.github.io/web-audio-api/#widl-AudioContext-resume-Promise-void Platform coverage: all Will ship in: 40 Preference behind which this will be implemented: none DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1154794 Other browser support: Blink Tests: dom/media/webaudio/test/test_audioContextSuspendResumeClose.html Thanks, Paul. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
