Hello!
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.
Context
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?