Edit: Note that in general, content will break even if it follows the intent of the policy (by only playing sounds in response to user input). This is due to the nature of Chrome's implementation of the policy.

If you maintain any WebAudio code the fix is below. For any code 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). Chrome 70 apparently restores the same implementation, so any content that broke before will break again, unless patched.

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

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

--

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. If either of those happens inside a user event handler, that context can play sounds. But if you create a context at startup and never call `resume` (like most WebAudio demos), the context will be muted regardless of whether it waits for user input.