Audio delays and performance issues in Safari on iOS/iPadOS

[morgant]

When used in Safari on iPadOS (14.x) with the Apple Magic Keyboard, the audio playback stutters and causes general performance issues.

Looking at keyzen.js, this may be due to the fact that the Audio element is created, loaded, and then played every time keyHandler() or level_up() is called (see

keyzen/keyzen.js

Line 95 in 9a75647

(new Audio("click.wav")).play();

,

keyzen/keyzen.js

Line 101 in 9a75647

(new Audio("clack.wav")).play();

, and

keyzen/keyzen.js

Line 132 in 9a75647

(new Audio('ding.wav')).play();

). I believe that Safari on iOS/iPadOS doesn't cache media files, so it may be re-fetching the .wavs on every instantiation of Audio.

I'd suggest starting by instantiating the three Audio elements only once and re-using them. If that doesn't work, migrating to the Web Audio API would probably fix it as they all could be loaded under one AudioContext.

[morgant]

Looks like PR #2 from way back in the day would have addressed this, but was closed. I'll clean up and submit a new PR.

[morgant]

I did a quick test of instantiating the sounds once, but upon testing I realized why it wasn't implemented that way: when typing quickly, the same sound will not be played for every key press as it may still/already be playing. It makes it sound/feel like it's not properly registering key presses.

So, I think that migrating to the Web Audio API is probably the best bet.

[morgant]

I have created an implementation using the Web Audio API and have tested in Chrome on desktop and Safari on iPadOS (14.x) and it completely resolves the stuttering audio & performance issues.

There's some minor fallout, including:

• Requires newer browser versions (though not super recent, see https://caniuse.com/mdn-api_response_arraybuffer & https://caniuse.com/mdn-api_baseaudiocontext_decodeaudiodata_returns_promise).
• Can't use jQuery.ajax() because it doesn't support the 'arraybuffer' data type.
• Audio won't work if index.html is loaded locally via file:/// due to CORS as the .wav files must be loaded from a web server via XHR/fetch(). Unfortunately, the Web Audio API can't reasonably copy data from an Audio media element to an AudioBuffer.

It would be very easy to fall back to the Audio media element playback implementation if the newer browser support is an issue for anyone.

I'll create a PR for review before I merge. Feedback is definitely welcome.

[morgant]

PR #19 has been merged, so this should be all set.