twrAudioPlayFile issues for Safari

[JohnDog3112]

I'm finally moving this to another issue from #48 about audio playback issues when using twrAudioPlayFile on Safari.

Browsers have a set of permissions(?) for playing audio on web pages. The main purpose of this is to prevent people from opening a web page and immediately having really loud audio auto-play into the user's headphones. This is why tests-audio makes you click a button to start the test. This button press is enough of an interaction for browsers to "unlock" the ability for JavaScript to play audio.

However, Safari has a weird exception. In the current implementation of the audio library, there are two ways that audio is played:

1. AudioContext: This acts as a global audio pipeline audio streams can be set to output to.
2. HTMLAudioElement: This is a built-in audio element in HTML that is given a URL to load and adds easier-to-use properties for control. If the audio element was added in the HTML it would come with user controls for volume, pause/play, and playback location, however, when creating it with pure JS the interface isn't available to the user.

In this case, Safari has weird permission settings for the 2nd method which is used for twrAudioPlayFile. For the AudioContext, a single button press remains enough to start playing audio. However, with respect to the HTMLAudioElement, Safari requires the user to click the play/button on each individual HTMLAudioElement via its interface. This is a problem in two respects:

1. The interface is never exposed to the user since it's supposed to be done programmatically
2. This would either necessitate having the user click the play button every time a sound is played via this method or, would involve having a limited pool of HTMLAudioElements that the user has to click on that are then sort of passed around with their URL being changed as a new URL is played.

I couldn't find a way around this permission system while using an HTMLAudioElement so I added an alternative play method for twrAudioPlayFile. So, if the HTMLAudioElement fails to play, it will fetch the audio file, decode it, and then play it through the AudioContext instead. I'll try to look into it a bit more to see if there is a better workaround, but I'll leave this workaround in until then.

flowchart TD
    G[twrAudioPlayFile] -->|URL| H(Create HTMLAudioElement)
    H --> I{Play Audio}
    I -->|Success| J(Carry on)
    I -->|NotAllowedError| K(fetch Audio URL)
    K --> L(Decode Audio Data)
    L --> M(Play Audio)
   M --> J

Loading