We have a specific sound that we have set “max Instances” to 4, and in the profiler we are noticing that there are way more than 4 instances of that sound playing. The sounds are being automatically played via “Fmod Studio Event Emitter” when it hits a collision volume.
I am unsure if the “Fmod Studio Event Emitter” abides by the “max instances” parameter in the event. Can someone shed some light on this? The number of “Fmod Studio Event Emitters” in my image below is 38, and are all triggering at once as a test – they are also all playing w/ 38 instances (even though I have it set max instance =4)
You’re looking at the event’s “voices” in the profiler, which is not synonymous with an event’s “instances.”
New voices are created whenever an instrument is triggered or selects a playlist entry to play, so one event instance can easily have multiple voices if its content requires it.
To view an event’s instances in the profiler, click on “Instances (Self)” in the profiler window’s transport bar.
Did you try with another steal option than “oldest”? Maybe your event is triggered 38 times at the exact same time and FMOD is not able to determine the “oldest” instance to steal?.. Maybe try virtualise.
I am unable to reproduce this issue. When I create a test project in Unity that attempts to play multiple instances of the same event, whose ‘max instances’ is set lower than the number of instances than Unity is attempting to play and whose stealing mode is ‘Oldest,’ the event’s “max instances” property is respected.
There must therefore be some way in which your game that differs from my test project, but I am unable to identify what it is without seeing it.
Have you tried rebuilding the banks, just in case it’s a bank synchronization issue?
Can you let me know what version of unity and fmod (and fmod package) you are using?
I was able to reproduce the issue, I’ve created a very simple repro case and uploaded a Unity Proj + Fmod project repro case here (using Unity 2020.1.8f1 and fmod 2.01.07):
Thanks for sending us that project. I was able to reproduce the issue without trouble.
I’ve checked with our developers, and it seems that this is actually the intended behavior. The “playing” instances are not actually playing; they’ve been created, exceeding the instance limit, which allows Studio to cull them.
However, as Studio reports all instances that aren’t actually in the stopped play state as “playing,” this gives the impression that there are more playing instances than there actually are.
