Audio cracking on web depending on server?


I’m making a mobile web-game using webgl in javascript, and I’m using the latest FMOD Studio javascript builds (currently using upstream/wasm) and I’ve been getting some audio cracking on “slower” & older devices and I’m trying to figure out why what’s going on. I undestand it’s likely a CPU bottleneck or a weird web-browser throttle behaviour, but I’m getting a bit desperate on figuring out why.

Here is a video of the issue, as recorded on an Iphone X, running safari:

At the begining of the video, I visit a locally-hosted server (using Five server, but I have also tried python3’s http.server with the same result) where the game runs acceptably at 50~ FPS and it sounds OK.
Then I switch to a tab to my github pages where the game still runs at the same FPS but the audio cracks for an unknown reason to me.

I’ve tried using different builds of the FMOD api, bringing the DSP buffer buffer size up to 2048x4 (I don’t really need a very fast-reactive buffer), but I have very similar results.

I know the issue is somehow related to performance because if I remove some of the game elements (like the pedestrians) I eventually get to a version where the audio doesn’t crack.
But I have had this happen even on a newer Iphone 13, and I’m getting occasional short cracks on my windows 11 desktop computer running firefox, so I’m afraid is something not fully related to CPU usage.

You can try find the game files at
And the github hosted game at

I’ve been testing with hosting it on itch (with their html5 hosting) and I have the same issue there as I have on my github pages.

The FMOD project build is a “mobile” build which barely has 4 tracks playing at the same time at any given moment, but at the sections of the beginning of the game where I recorded this video it’s not even 2 tracks.

Any clues? Is it possibly something related to the FMOD build (upstream vs fastcomp, or wasm vs other things)?

I agree this does seem to be related to performance, and HTML5 is notorious for performance issues due to its lack of threading support. Increasing the DSP buffer size is a good start, you could also try changing the Loading Mode of any streaming assets to Compressed or Decompressed.
For best performance on HTML5 you can try enabling SharedArrayBuffer, which can be set from the server header with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp policies.

Hey thanks for the reply!

I’ve been messing with the loading mode of my assets, tried having everything compressed, everything decompressed, everything streamed, also tried trimming my audio assets (to reduce filesize and possibly processing overhead of larger files), but I got very similar results.

I also tried enabling the SharedArrayBuffer in my itch upload, and while it feels it runs a bit faster, I still got some audio cracking.

In the end my saviour was of course to just limit FPS to reduce CPU usage overall.
I have a feeling that the browsers limit CPU usage very differently and randomly, and iOS was throttling Safari for some reason even on newer devices like iPhone 13. Maybe some energy settings or that my javascript was warming the phone fast enough to thermal throttle the browser (?).

Also I feel they might have this cpu “limit” disabled on local-network IPs (192.168.X.X) and that’s why I was getting different performance on different servers.

In any case since I can’t requestAnimationFrame at a specific framerate I just ended up skipping everything except Studio.System::update if I was going over my limit of 30 FPS. Making sure the sound gets streamed at whatever frame-rate I get from the device.

My project build ended up just being bank of compressed (ogg) files, most of them streamed, and setting the DSP buffer to 2048x4 for now.