After reading about voice stealing here I thought that setting a low max instances and stealing to virtualize, would mean that only the loudest events would be heard. But this doesn’t seem to be the case.
I have 10 instances of an event playing in the scene, but even if the listener is really close to an instance, I do not hear it, although it is clearly the loudest (I can hear this when setting Max Instances to infinite).
Am I misunderstanding something? Basically I just want virtualize all sounds except the nearest/loudest. These are looping sounds.
How are the volumes of your event instances being set? I ask because the FMOD Engine calculates audibility by checking for a specific list of sources of volume adjustment for each event instance, so if your event instances use a method that’s not on the list, that particular source of volume adjustment may be ignored.
Looking at your video, I can see that your events have a “distance” parameter. I’m guessing this is used for volume automation, but exactly which volume properties are being automated on it? The event’s master track volume fader? An audio track’s volume fader? An instrument’s volume fader? The fader of a gain effect?
I did some more experiements, and it seems to be reloated to the Google Resonance spatializer. Here is a video showing it:
I created a new empty project, and as you can hear the FMOD spatializer works as expected (except that it stops the closest event when new ones are started), but when using the Resonance spatializer, the oldest instance is never played once the voice limit is reached, even when the listener is right next to it.
I’m afraid I haven’t been able to reproduce this issue. When I test here by mimicing what you do in your videos, creating new instances of the event at a greater distance from the listener than the first instance does not cause the first instance to fall silent when using a spatializer effect; and with all three effects, event instances seem to virtualize and un-virtualize correctly such that the instances closest to the listener are audible.
It’s therefore likely that I must be missing some key part of the reproduction steps for this issue. Perhaps it only occurs in certain versions of FMOD Studio, or there’s some feature of your project not shown in the video that causes the difference in behavior. Which version of FMOD Studio are you using? Are you able to send us a project that exhibits this behavior?
Aha! Using your test project, I was able to reproduce this issue in version 2.02.03 of FMOD Studio, but not in version 2.02.15. That suggests that this issue existed once, but has since been fixed.
Checking at our records, I can see that version 2.02.03 did, indeed, have a bug that caused object spatialized event instances (i.e.: instances of events using the object spatializer and Resonance Audio spatializer) to not take into account additive gain when calculating event instance audibility, resulting in FMOD incorrectly detecting all event object-spatialized instances as being equally loud. When FMOD needs to virtualize an event instance and has multiple equally-loud instances to choose from, it uses event instance age as a tiebreaker, resulting in the behavior that you’ve observed.
Fortunately, this bug was fixed in version 2.02.05, so all you need to do is update FMOD Studio and the FMOD Engine to that version or later.
Hi Joseph. It seems that I have a similar issue were I have many instances of one event that have some gain volume attenuation based on distance (and other parameters manually tweaked in Unity per instance) that do not virtualize based on audibility but rather on age (see this video capture : https://www.youtube.com/watch?v=pwpXQOxIVLc).
If i’m right, that means that I might be experiencing the same bug as @deHaan since my version of FMOD is 2.02.04. Am I right ? If so, what version would you recommend me to try in order to minimize project migration risks ?
I can’t know if you’re right without inspecting your project, but it definitely sounds plausible.
All versions of FMOD Studio within a given major version are compatible, and we avoid introducing behavior changes in patch versions, so in theory any version from 2.02.05 onward should be fine. Perhaps 2.02.13?
Hi Joseph. I tried to switch to 2.02.13 and I encountered the same Issue.
I opened my project with the new version of fmod,
I checked that my events were correctly set to virtualize stealing with a max instance of 1,
I built my banks,
In this profiler capture, I observe that the non virtualize instance is switched when I change room (therefore when new instances of my event are loaded). My listener is moving and is getting closer to other instances which stay virtualized, compared to the instance that is currently audible but still further away.
I tried this with different version of fmod including 2.02.05, 2.02.13 and 2.02.17 and I still get the same behavior.
In that case, the behavior you’re seeing must be caused by something other than the bug deHaan was running into. unfortunately, without more information about your project, there’s no easy way for us to guess the cause. Are you able to send us a project containing an event that exhibits the issue, so that we can investigate it?
You can upload files in the uploads tab of your profile on this site, provided you’ve registered at least one game with us. Registering only takes a few minutes, and lets us know what kind of games people are using FMOD to make.
I’ve responded to your colleague via email on this issue, but for the purposes of our forums:
The behavior being observed is caused by the audibility calculation used for virtualization only taking into account accumulated gain (i.e. fader, attenuation from spatializers, etc.) on the Event’s master track, and not taking into account gain applied to the child audio tracks.
The easiest workaround is to consolidate your Spatializer effects from the child tracks to the master track.
Technically this is working as intended, but is understandably confusing, so an improved audibility calculation and some documentation changes have been added to our feature/improvement tracker. However, a change to the audibility calculation is significant, and would have to be in a major version update (i.e. 2.03) if it was to be implemented, so it’s unlikely to occur for some time if at all.
