Separating FMOD banks to get around Unity WebGL's 2GB limit


Recently, I posted this topic, and while my initial question has been answered, after some further reading I realized that the problem I’m trying to tackle is much bigger than I initially thought.

HTML5 builds in Unity are not only single-threaded, but they also have a limit of 2GB of usable memory. To get around this, I figured that playing FMOD events directly through the browser instead of through Unity would not only increase performance, but also use less memory reserved for Unity.

To test this out, I created a custom version of the RuntimeManager class that uses preprocessors to check if it should use the regular RuntimeManager, or instead use extern functions to communicate with some code in JavaScript that replicates the RuntimeManager in Unity.

After trying it out, I noticed that audio was stuttering a lot, not all audio was stuttering though. My assumption is that the stuttering is caused by 3D sounds, for I update the 3D attributes of both the listener and emitters whenever they move.

Possible solution
My initial possible solution to this problem is to only play 2D audio directly in the browser instead, leaving all the other audio to play as usual using FMODUnity. This will hopefully fix the stuttering problem.

To do this, I could put all the 2D audio events in separate banks, then load all 3D banks as normal using the Studio Bank Loader, but load all 2D banks in JS directly using the StreamingAssets folder that is present in the HTML5 build.

I am not sure if this will work though, as I do not know if FMOD’s implementation in Unity preloads all banks beforehand, and if these banks are even taking up memory reserved for the Unity HTML5 build or not.

Is any part of my possible solution even possible? Will this show any tangible difference in performance and/or memory usage?


While this solution is possible it might be worth trying to solve the stuttering in the Unity scene first. How many 3D sounds do you have moving in the scene? If you choose development build do you see any FMOD errors in the console?

Would it be possible to get a link to the project so I have a look at it on my side? You could DM me the link if you prefer.

I think solving the issues with the 3D sounds will have the greatest impact on performance.

This can also be done by changing the setting in the Unity Integration | Settings - Initialization:
This will mean you are in charge of loading the and

Hope this helps!

Hey, thanks for going into detail in your reply!

Good to know I was on the right path.

The stuttering that I am experiencing with 3D sounds does not happen when using the default FMOD implementation for Unity, the problem only seems to appear when using my JS implementation, where Unity uses extern functions to update the 3D attributes of the event instances in JS.

First I thought it was a difference in framerate between JS and Unity that was causing the problem, but after some testing with different framerates it did not seem to make a difference.

Because I am looping through all the event emitters in the scene every frame, calling an extern function to update the 3D attributes of each one, I suspect that this is causing the stuttering. The implementation of the studio listener works in the same way.

I tried to optimize this by only calling the extern functions when the 3D attributes have changed since the last frame, but this did not solve the issue.

Sadly, I am not able to share the project, but I hope that my explanation of the implementation is somewhat clear.


Thanks for the further explanation. An alternative option is to have a look at our documentation outlining Memory Management: FMOD API | White Papers - Memory Management. It touches on subjects that will allow you to limit how much memory FMOD uses, which may give you the control you are after rather than trying to split the systems between Unity and JS? Let me know if that helps. I will also link to the FMOD API | Effect Reference documentation which lists all our effects and their impact on the CPU which may help in limiting memory usage.