Robotic sound on WebGL build, tips to avoid that?

Unity
1

Hi! I am developing a Unity musical themed game called Music Rush and distributing to WebGL, check it out here: Music Rush Totem by Canvas Games

We have been experiencing issues on the audio becoming Robotic when the device (browser or the computer) has low memory. We already changes to load and load every single song as a separate bank. What advices do you have for that?

We can try to:

  1. Reduce the audio quality on build
  2. Reduce the audio sample rate on build
  3. Use import playback setting “Sream” on every song

I am out of ideas apart from these!

2

Hello, I have a couple of ideas:

  • Increasing the audio buffer
  • Serving CORS headers where SharedArrayBuffer are available in-browser enables a fast path for mixing
  • Maybe increasing the frequency of calls to update, by trial-and-error that fixed a lot of drop outs on my project, though I’m just making an audio player without a game engine.

Here’s the platform info in the docs: https://www.fmod.com/docs/2.02/api/platforms-html5.html

Hope that helps!

3

Thanks for the tips!
Changing the buffer dsp parameters indeed affects it directly. However, it is very hard to debug on which devices / browsers it is best set. Some runs well and other don’t, and it is very easy to reproduce when opening in a mobile browser. I know now that increasing the Buffer Lenght helps. If there is any tips on how to debug that, would be great.

About the othe suggestions, I haven’t tried yet. Is there any links you can suggest for us to understand what you mean?

4

Glad to hear adjusting the audio buffer helped!

I kind of know what you mean about debugging for different browsers. For some reason my project still pops a lot on Firefox, so I ended up narrowing to supporting Chrome and Safari. Kind of concerned about mobile, which I haven’t started testing yet…

The FMOD Html5-specific doc link I wrote above is a good place to start for getting AudioWorkletNode/SharedArrayBuffer optimization working (the Browser Compatibility section). You’d need to have control over the server though. To check if it’s working, if you make a build with the logging version of FMOD, it logs to the browser console if it’s using fast path mixing or not when the system initializes.

5

Hi,

The suggestions @aishi1 has made are good, and the steps you’ve taken in reducing sample rate/quality and dynamically loading your banks are as well. Besides simply making your events less complex, and reducing the use of computationally expensive effects, our HTML5 platform doc outlines some significant performance points.

Most notably in your case - “streaming” with HTML5 is often redundant as there is no disk to stream from, and the sample data that would normally be streamed is already loaded into memory anyway. As a result, in Studio I would recommend disabling streaming for assets on HTML5, which will cause the asset to use the default “compressed” loading mode instead and should be more performant. See the Loading Modes section of the Studio manual for more information.

Also, with the Debug Overlay enabled, or when using Studio::System::getCPUUsage, what kind of numbers do you run into? If you haven’t already I would also recommend enabling API error logging and setting your logging level to log in your FMOD for Unity settings and seeing whether you run into any specific warnings/errors in a development build when you run into performance issues.