shortwave - those are interesting links - it sounds like it's an iOS bug that has been around for a while, and it definitely sounds like it's something to do with iOS changing the sampling rate as mentioned earlier in the thread:
[quote:1w4jr61m]I believe the issue is caused due to resetting the audioContext.sampleRate prop, which seem to happen after the browser/OS plays something recorded in a different sampling rate.
[quote:1w4jr61m]I noticed that if you play a video using a <video> tag, it sets the context.sampleRate value to whatever the video's audio was encoded at. It seems as if iOS Safari has one global sampleRate that it uses for everything...
This global sample rate appears to persist across page loads and is shared between tabs and browser instances. So, playing a youtube video in another tab could break all your decoded audio.
So under some circumstances iOS ends up playing audio buffers at the wrong sample rate, which probably corrupts the audio and sounds distorted.
I think this confirms it's an iOS bug and not something wrong with our own code, so the best we could do from here is figure out a reliable way to reproduce it and forward it to Apple. I think the repro will look something like:
1. Open a C2 project in Safari which plays some audio at 44.1KHz
2. Close Safari
3. Open something else that plays audio at a different sample rate, e.g. 48KHz
4. Close that and go back to Safari
5. See if the audio is distorted
However as per usual in bug reports, we need absolute specifics for every step. So I think it's just a matter of finding something reliable for step 3 (e.g. a youtube video or something public and reliable like that).
I've looked at some of the workarounds and they look very difficult - they say things like "just recreate the AudioContext", but in our engine that would mean tearing down and rebuilding the entire audio routing graph, and possibly re-decoding audio buffers. That's complicated and we have no code to cover that right now since normally there's no need to ever do that, and implementing it is enough new code that it is likely to cause as many problems as it solves (as already happened recently with an Android audio bug, and that was much simpler!) Other workarounds like "just play an audio buffer at this frequency" don't make sense, because it's already doing that when you play a new sound when coming back, but it still sounds distorted.
The good news is I think this should have limited impact - it seems unlikely it will affect everyone, it's just certain combinations of playing something else in between Safari.