fix: Web, soloud will eventually stop working in iOS Safari

[yangyuan]

Description

I eventually able to repro this in all mines and my friends iOS devices. Though I haven't found a fast and stable way to repro.

Steps To Reproduce

1. An iOS device, not in silent ring (vibration) mode. (It's more complicated in silent ring mode)
2. Use built-in Safari, go to https://victorious-dune-08f691f1e.6.azurestaticapps.net/ source code FYI. https://github.com/yangyuan/flutter-issues/blob/soloud/lib/main.dart. The app was built with flutter build web --pwa-strategy=none --release, I use --pwa-strategy=none to get rid of cache only.
3. Click "Play sound", it shall be working first time you load the page.
4. Randomly play around, lock screen, leave it idle, or exit/kill/reopen Safari, or go for a coffee. At one point the "Play Sound" will not work anymore, this usually take < 10 mins to happen.
5. Once above happens, then there is a stable way to repro:
   5.1 Refresh the page, click "Play sound", it shall be working.
   5.2 Lock screen or exit Safari, then come back to the page.
   5.3 click "Play sound", it shall not make any sound. Click "Reload AudioSource"
   5.4 click "Reset Soloud", then click "Play sound", it's back to working.

Expected Behavior

Soloud should always be able to make sound.

Screenshots

N/A

Additional Context

I am working on a game which is targeting mobile browsers.
I also encountered similar issue with AudioPlayer. But unlike soloud, I didn't find a way to recover AudioPlayer. AudioPlayer seems also not interested in looking into Web issues.

My two-cent analysis

1. "Reload AudioSource" did not work, only re-initialize soloud works. So, my biggest suspicion is around device management. Maybe lock and unlock the screen or quitting the browser trigged something, (for example. a device change?)
2. My second suspicion is around service worker. I'm very new to this. Maybe the service worker died for some reason? Maybe iOS browsers manage service worker in a different way? All tested devices were working all fine in the beginning and then, at some point, can stably repro this. Could this because there was something getting added up and eventually trigged some limit?
3. I still need find a stable way to repro, but sometimes soloud in one website trigged the sound from another website which failed to play earlier (I was testing soloud in different websites, these websites do not share anything, different domain different asset, and somehow, they can interfere each other?!). This further let me believe there is some issue about device or service worker.
4. Its more compilated when silent ring mode is on. The tested page may or may not make sound in the beginning. But on all of the tested devices, soloud eventually make no sounds when silent ring mode is on. Even reset soloud won't help. This is just for your information; silent mode making no sound is still acceptable.
5. Physical devices seem also have different but in-a-way also very similar issue fix: AudioSources seemingly become invalid after leaving standby (on Android) #126

[alnitak]

Physical devices seem also have different but in-a-way also very similar issue #126

I was thinking exactly of this issue you mentioned that got me crazy also yesterday, when I tried again to look into that! Maybe this and the other one are related because #126 seems not to be caused by idle, doze mode, or memory GC-ed.

TBH I don't know yet where to look also because on the Web is more complex to debug native code and I am not sure where the problem comes from (ie, OS, browser, Dart Web, wasm, C libs, or my C).

I'll try to dig deeper, but please tell me you find anything else!

[callmephil]

For me, mobile web doesn't load at all, I'm initializing soloud in my main and compiling for wasm.

Regarding iOS, Safari and Chrome have autoplay safeguards (It's not documented, but it's happening for audio APIs too), meaning you can only play an audio after physical interaction with the screen. You have about 900 milliseconds to play an audio; otherwise, it will not produce any sound.
The workaround is quite simple: open your buffer and inject the audio within that timeframe. You should keep on using the same audio context until the next physical interaction. At this point, you close it and open a new one. Take this with a grain of salt, I've been trying to solve the mobile browsers issue for a few months already, and these are my observations.

@alnitak I'm not sure how you handle web, but I've found this fork of flutter pcm sound https://github.com/keyur2maru/flutter_pcm_sound/tree/master/lib that somehow gets things fixed, but the audio samples are scrambled when receiving a 24000 sample rate PCM file.