I have a parameter that triggers automation to turn the volume of one of the tracks in my event on or off. If this parameter is edited two or more times during one playthrough, there is a noticeable desync between the two tracks. Each edit of the parameter causes the desync to get worse until the song loops. Why does adjusting the volume of one of my event’s tracks cause desync?
I found this post
https://www.fmod.org/questions/question/tracks-going-out-of-sync/
which talks about editing the Priority of an event to avoid desyncing. It worked, but felt a little dirty, so I took to the manual now that I had some ground to stand on.
The section on Virtualization sheds some light on the issue:
https://www.fmod.com/resources/documentation-studio?page=advanced-topics.html#virtualization
It seems that (at least in Unity land) the FMOD_INIT_VOL0_BECOMES_VIRTUAL setting defaults to on. This means that when you set a track’s volume to 0, it is virtualized. The documentation suggests that virtualizing does not mess with the playback position of the track, but I do not think that is entirely accurate as I was facing heavy desyncing until I changed my event’s Priority to Highest. Maybe the playback position stays accurate, but faces some hiccups when the virtualized track is loaded back into memory?
The section on Priority talks about what the various values do:
From what I can tell, there is no immediate drawbacks to changing background music’s Priority to Highest. It seems to matter when the total number of events/instruments playing reaches the maximum (configured?) value.
Hi Tanner,
There’s a bit of confusion between virtualization of the low level and virtualization of event instances. VOL0_BECOMES_VIRTUAL will virtualize the low level voices, which are the instruments when using an FMOD Studio project. Since you mentioned this happening in a song event, I will assume the instruments’ assets are set to streaming. This can also play a factor in the desyncing because of their need to look ahead a little bit before playing. A workaround to this can be to set the assets desyncing to not be streaming, however this does come at the cost of more memory usage.
Setting the priority to Highest is to ensure that none of the low level voices (re: instruments) within this event are stolen. There’s no issues or downsides to setting this property, and is recommended for events such as music that you don’t want to get stolen when the voice stealing system kicks in.
The event stealing vitualization and the max instances properties only affect the number of instances of this event. A virtualized event instance will mute the master bus of that event instance but the timeline will continue as normal. The max instances dictates how many instances of that event are allowed in the game world before the stealing behaviour specified is applied.
For your issue, please set your music events priority to Highest.
Thanks,
Richard