Chrome autoplay policy changes can cause large delay in evaluation audio responsiveness about estuary

[dktr0]

This should now be resolved courtesy of a significant recent refactor, I think. (Rendering is now primarily against the audio context clock.)

[SpencerPark]

This crept back in. I think the clock gets stuck rewinding and never issues a sample as the clock never progresses until a sample is played which is what would trigger an effective resume().

If the user clicks the loading icon then there is no issue as an interaction happened before the context was created. If the user lets the icon fade from the timeout then we need to resume the context after an interaction. A onetime click handler on the document body could do that.

[dktr0]

Can you clarify the circumstances that are necessary to reproduce this, to help me understand it better? (I tried just letting the loading icon fade - and then going to make a sound in solo mode - and it works for me on Chrome and Firefox on OS X.)

[SpencerPark]

It is specific to chrome 71+ (released in Dec of 2018 so still somewhat new). A better link I should have originally included is the following https://developers.google.com/web/updates/2018/11/web-audio-autoplay.

If you create the AudioContext before there has been any user interaction with the page (like a click), the context gets automatically put into the suspended state. You can check with ___ac.state. Estuary doesn't create that context until the icon goes away. If the user clicks then an interaction has occurred and so the ___ac.state === 'running'. If the icon fades, an interaction has not occurred so ___ac.state === 'suspended'.

In the second case, the context must then be resumed (___ac.resume()). Calling start() on a node will implicitly do the same thing as calling resume. Calling start was what I think prevented this in the past. Since the ___ac is suspended the clock doesn't advance so the improved renderer keeps "rewinding" but never enough to try and play any samples because it gets further and further ahead of the ___ac.currentTime.

To summarize, on chrome version 71 (I am on 71.0.3578.98 and can reproduce this) let the icon fade without touching the page at all and then try and play sound in any mode or run ___ac.state in the dev tools console.

[dktr0]

@SpencerPark I think a way to make progress on this issue would be to change the splash screen as follows - it also displays word Estuary (relatively large/visible) and (rather smaller) "Loading..." until loading is complete at which point "Loading..." becomes "Click to Start". We might bump this ahead of the Nix stuff since it will help with upcoming workshops (people going into the interface without clicking is a source of confusion in that setting).

[dktr0]

It's really killing two birds with one stone because the splash page is a bit too cryptic anyway.

[SpencerPark]

@dktr0 I agree. I'll start working on this today.

[SpencerPark]

I think there is a chrome bug, on 72.0.3626.109, after calling ac.audioWorklet.addModule(...) on the suspended state, the state remains "suspended" but it continues to works as if the state was "running" (bypassing the autoplay policy altogether). This is good for us but confused me for a bit trying to check if this was fixed or not. Since it seems like a bug I will continue working on properly invoking resume() but wanted to document this in case others try to reproduce with new webdirt.