iOS 15 sound does not resume when woken from sleep

[yaustar]

Test Project: https://playcanvas.com/project/878048/overview/ios-15-sound-resume-issue

• Set the autolock in settings to be 1m
• Clear Safari Cache
• Open https://playcanv.as/e/p/o6Ew3BtU/
• Touch the screen to start playing sound
• Wait to phone autolocks
• Wait 20s
• Unlock phone
• Audio does not resume, even after touching the device

(Note, may take a few tries)

There's a script that is printing out the status of the context. When it locks, it has interrupted state and when it is unlocked, it prints 'running' which is odd. Do we need to create a new Audio Context because the old one is corrupted?

[yaustar]

Risen in priority as a vendor cannot pass a TRC with this bug

[yaustar]

Related issue with another JS library: goldfire/howler.js#1525

[yaustar]

Reading more into it, I don't think there's an easy solution to this. To get around this issue, we would have to recreate the entire sound system in PlayCanvas and the sound components in the scene when this happens

[mvaligursky]

sounds similar to graphics engine handling context lost and restored events, where we need to re-create all graphics resources. Perhaps something similar is needed for sound.

[jpauloruschel]

Reopening due to issue re-appearing: https://forum.playcanvas.com/t/ios-audio-not-resuming-after-standby/26408

[jpauloruschel]

I've been investigating this issue and here are my findings:

• Issue occurs consistently 100% of the time on iPhone 13 Safari and Chrome;
• Issue never occurs on any non-mobile device;
• When issue occurs, WebAudio's AudioContext has a running state and successfully returns all .resume() requests;
• There are 2 ways to programmatically determine the AudioContext is actually broken:
  • attempt to play any sound (which will succeed), but will actually never finish (onended event will never be fired)
  • query AudioContext.currentTime, which will have the same value forever

I believe the issue has something to do with PlayCanvas not correctly verifying if the AudioContext is unlocked before being used (which should not be done), leading to an undefined internal state in the browser's implementation. Currently still working on a way of fixing this.