I’ve started to look into a performance side of things in our Unreal project and play more with the virtualization (Unreal 5.1 with FMOD 2.02.16).
We have a lot of audio sources on a map like vending machines or AC units, that produce sound constantly. If I understood the documentation correctly, Virtualization should be helpful in this case, so all of these are limited to max 5 instances with stealing set to Virtualize. The issue comes when I check the CPU in the Profiler and often these events with virtualization use a bit more and sometimes double of the CPU percentage than when I turn off the virtualization completely.
Here’s one example with 35 instances which are playing, the first part are without stealing and the second with the virtualization on. The player character was outside of most of the audio sources in both cases. The event itself have one continuous loop playing.
Of course, we could implement custom audio culling and start instances only when player reaches threshold distance but I would expect that virtualization mimics that and the CPU usage should be very low when virtualizing (as mentioned in several forum posts) and not similar or higher in average. Am I missing something here?
That behavior does seem a bit odd, and from your description I don’t think you’re missing anything. If possible, can I get you to upload the profiler session to your FMOD Profile so that I can take a look and hopefully diagnose the issue?
You appear to uploaded the raw profiler session from your project’s metadata, which won’t allow me to import it into FMOD Studio. Please uploads profiler sessions that have been packaged by right clicking on the session in the Profiler window’s “Sessions” tab and selecting “Package Selection…”.
After taking a look at your profiler sessions, and doing some testing to try to reproduce the issue, I suspect this is a case of premature optimization. I can confirm that using the “virtualize” stealing mode does make a difference to CPU usage - when using around 300 instances I was able to observe a significant difference in Mixer (~50% vs ~25%) and Update (~50% vs ~45%) CPU usage when playing without stealing compared to virtualizing the same instances with max instance setting of 3. In your case, the voice and event instance counts in your sessions and project aren’t large enough to incur a significant difference, and you may not need to optimize your events’ stealing behaviors.
Thank you for testing it out. I previously sent the profiler sessions from our testing map, where I specifically added only the assets with continuous audio source that should be virtualized. We have more instances in our maps. I understand that virtualization doesn’t have significant difference with a small amount of instances, that’s why I was confused CPU usage is even higher with Stealing disabled.
Unfortunately I can’t confirm the same behavior on my side, when I used more than 300 instances there’s still no significant difference (44% vs 49%). When using even more distances, the difference is even lower. Our project doesn’t use more than 200 instances now and using around 22% CPU, so it’s not that important at this moment, but it will gradually grow and I wanted to be prepared early with the optimization.
Thanks for uploading a profiler session with a lot more instances running at once - I can definitely see the behavior you’re describing now.
The reason you’re not observing a significant difference in CPU usage in the session that when using “Virtualize” compared to other stealing modes, despite the difference in active event instances, the total count of underlying voices is the same, and difference in active voices is small. The performance difference when virtualizing is normally caused by a large difference in the amount of active voices. I suspect that if you were to increase real channel count of your FMOD System, you would increase the amount of real voices the VendingMachine_Buzz event would be playing, and therefore observe a larger difference in performance.
That said, this specific issue would be best handled reducing the amount of instances of VendingMachine_Buzz playing at once in your game, so I would recommend doing as you’ve noted in your original post and implement a distance based culling system.
It’s worth noting that while FMOD’s virtualization system has the same functional outcome as a culling system (i.e. no output produced by virtualized/culled instances), virtualization still maintains the event instances and their underlying behaviors, meaning that the FMOD System still processes things like playback position, timeline logic, API commands such as setting parameters, etc. and advances the underlying DSP clocks, which necessarily still incurs CPU overhead. With a culling system, the culled event instances no longer exist, so the FMOD System does not have to process anything.
Thank you. I can confirm that when there’s greater difference in active voices, the virtualization has more impact and Mixer CPU usage is noticeably lower.
My original assumption was that virtualization is useful specifically in these cases, where great amount of assets with continuous sound is scattered throughout a large map, like torches, buzzing lights etc. and it should save CPU usage significantly. Of course, it is still very much useful and we will utilize it, but for the high number of instances where we don’t use or need parameters/playback position/logic a culling system is necessary.
Thank you again for the clarification and your time!
