Sound does not work well on some browsers on iOS

[dcarabott]

Trying to play any clip on the following test page will result in no audible output while on iOS: https://pixijs.io/sound/examples/

Tested on the following iOS versions:
16.6
16.6.1

Tested on the following browsers:
Chrome
Safari
DuckDuckGo

It works just fine when connected to headphones. After its disconnected, trying to play a sound will result in a brief sound and it goes completely silent again.

[bigtimebuddy]

Duplicate of #175?

[dcarabott]

@bigtimebuddy not sure, here the issue has nothing to do with the headphones. The sound was already not working before connecting the headphones. I've only mentioned the headphones example for more information. But yes, issue might be related.

[bigtimebuddy]

Can you try the fix mentioned in that thread and see if that works?

[dcarabott]

@bigtimebuddy tried the fix mentioned on the other thread but it didn't work. The problem on our end doesn't start when the user switches tabs or connects/disconnects the headphones (I'm guessing this is what the workaround tried to fix). There is no sound from the get go.

[gpoole]

Have had this issue on multiple iOS devices and versions (oldest was 16.5) with the example pages and it seems to be tied to Safari muting WebAudioContext (but not <video>/<audio>) when the ringer is muted. The linked issue suggests a workaround which involves playing an empty Audio element before creating the context.

The "correct" fix is changing the audioSession.type:

navigator.audioSession.type = "playback"

I have found that setting that allows the examples page to play audio with the ringer off when previously it didn't. It would also explain why the audio works through headphones but not when the headphones are disconnected.

[gpoole]

Looking into the AudioSession spec indicates that "playback" may not be appropriate for all apps, as it can interrupt other system audio that might be playing. Adding it to WebAudioContext initialization in @pixi/sound might not be the right fix. Maybe this just needs to be documented so users can set the session type as needed by their app?

It doesn't look like any other vendors are implementing the AudioSession spec so I'm not sure about the implications down the line if they do.