Hey,
I have an audio event that is using Quietest stealing behaviour and has Max Instances set to 3. However when playing the event, it seems that older and definitely quieter instances get prioritized over new instances, which simply never start playing. See Dropbox - 2023-08-31 16-41-16-fmod-stealing-bug.mp4 - Simplify your life for an example. In the later part of the video I switch the event to Virtualize stealing mode, which still works in a curious manner.
EDIT: Using the Oldest stealing mode things sort of work as intented, but there are cases where the audio isn’t played at the player location, and stealing Oldest instances could result in abruptly cut sounds.
I’m using fmod C++ API version 2.02.17, which according to the release notes has fixed some bugs relating to the stealing logic. Is this a known issue, or could I be doing something wrong?
It seems I may have found some sort of solution. Increasing the size of the sound (in this case from 55 to 70) seems to make new instances always override the old ones. However I don’t think I understand what is happening exactly. The new sound was sometimes cut off while it was obviously louder than the tail of the old sound which was playing.
Nevermind, when the event is played further from the listener the issue occurs again. It seems the priorization goes out of whack whenever the audio is further than the spatializer min distance.
Thank you for the video, the project looks amazing!
Just to confirm, is the event that you are experiencing the issue with the weapon firing? Or is it the sound connected to the projectiles?
Have you connected an FMOD Studio | Profiler to the project and watched which instances remain active when you are expecting them to stop? It might be worth keeping an eye on the FMOD Studio | Profiling - API Calls View, for any strange behavior. Once you have a session recorded could it please be uploaded to your profile?
Would it be possible to see how the events are being triggered via code as well?
Thank you!
Yes, it’s the weapon firing sound.
Before I submit a profiler session - am I right to assume that the quietest stealing policy isn’t based on the actual waveform generated by an event, but instead uses a formula like instance_volume * instance_master_track _automation_etc * spatialization_attenuation, and doesn’t let a new instance play if it would be quieter than old instances based on that formula? That would explain the behaviour I’m seeing, and in that case I believe we have to roll our own voice stealing logic that takes all necessary stuff into account.