Heads up to anyone working with WebAudio: Chrome 70 (due in October) will restore a content policy that breaks most/all WebAudio content unless it's been specifically fixed to follow the policy.

If you maintain any WebAudio code the fix is below. For any WebAudio content that hasn't been fixed and isn't maintained, expect it to stop working soon in Chrome. :(

--

Background: This is part of the "no autoplaying" policy that rolled out in Chrome 66, and was reverted for WebAudio a few days later because it broke everything (including Chrome's own webaudio demos).

Past HN discussion: https://news.ycombinator.com/item?id=17079724

Policy info: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#webaudio

Chrome 70 apparently restores the same implementation, so any content that broke before will break again, unless patched.

--

Fix and tech details:

The easiest fix is to add a redundant `ctx.resume()` call to any user input event handler. Once that fires the audioContext will work normally.

Basically Chrome's implementation of the policy doesn't look at when an AudioContext plays sounds

, it only cares when (a) the context is created, and (b) `context.resume()` is called. As long as one of those things happens inside a user event handler, that context can play sounds. But if (like most WebAudio content) you create a context at startup and never call `resume`, you'll run afoul of the policy and no sounds will play, regardless of whether you wait for user input or not.