Our current project requires many unique instruments to be synchronized in a single loop (currently the aim is to have nearly 300 unique tracks). Naturally, all 300 of them will never play at the same time - realistically only up to ~ 20 should be audible at once. But my main question is this: how do we keep them synchronized? The user will be able to manually pick different tracks during playtime (so at any point, they can change track 204 for track 152 for example), and we need this switch to happen smoothly – I.E. the moment a new instrument is picked, it has to be immediately audible and perfectly in sync with the rest, while the previous gets muted.
My first instinct was to put all the instruments in a single event and disable virtualization for that event – and while that mostly achieved what we needed – I.E. the tracks remained mostly in sync even when they were getting muted/unmuted, it presented a different issue – I was constantly using up all 256 active voice slots (even if almost all of them were at 0 volume). This meant that no other SFX’s were audible.
If I do enable virtualization, and then suddenly start changing the volume of some of the instruments – they get completely out of sync (it seems like they mostly sync up at the end of the loop, but that’s not good enough – we need them to be synced immediately when they become audible).
So, is there any way to keep instruments synced together without keeping them as active voices? Or alternatively, is there any way to start new instruments in sync with other, already playing instruments? I’m looking for any kind of solution that would allow us to achieve synchronization.
For context, we’re using FMOD Studio 2.03.11 and Unity 6000.3.0f1 with FMOD for Unity 2.03.10. None of the assets are set to “stream”. None of the instruments are asynchronous.
Voices becoming desynced when going from virtual to real should have been solved in 2.03.00: Detailed Revision History.
Another contributing factor could be the encoding format used on the assets. Would it be possible to test with PCM or Vorbis encoding settings and let me know is that helps.
The desynchronization happens on builds with both PCM and Vorbis settings.
I tested inserting 8 event instruments to be played among 100 other instruments, and these 8 even instruments did in fact seem to be perfectly synchronized with one another. I’ve yet to test this at a larger scale, but this might be the exact solution to our problem.
Going back to the virtual instrument desynchronization that should’ve been solved in 2.03.00 - I’ve noticed one interesting thing - the desynchronization only seems to happen ONCE per computer restart - I.E. the first time I play an event with a bunch of virtualized instruments, they are completely out of sync with one another, and the moment this event reaches the end of the loop, they suddenly sync up together. This problem doesn’t reappear even if I quit out of the build and turn it on again - it only comes back after I restart Windows itself. In previous FMOD versions, the desyncing would be constant, so this problem is way more manageable now.
Our current workaround is to immediately set the timeline position to just before the end of the loop when starting the track. This forces the instruments to resynchronize right away, and the problem does not reappear until the next system restart. If there is a recommended way to preload or initialize anything to prevent this from happening in the first place, I would appreciate your advice. In either case, this workaround is sufficient for us at the moment, and I’m marking this as solved.
While preparing the FMOD studio project to be uploaded I noticed that I made a mistake - I was using assets marked “stream”, and they were the ones getting out of sync during my original testing. I apologize for providing incorrect information in my initial post. The whole “instruments only syncing up at the end of the loop and only once per restart” situation seems to only happen when using a mix of streaming and non-streaming assets, which I imagine is not unexpected behavior.
Having switched off the “stream” options on all of them, I ran into a different problem - there was a huge delay before the invoked event would actually start playing (~5 seconds or so). Just like before, this would happen only once per PC restart. However, invoking description.loadSampleData(); for the event in question during initial loading of the game fixed that issue entirely.
If you’re by any chance still interested in the project when it’s in the state of “desync once per restart while using a mix of streaming and non streaming assets” , then here’s a link to the FMOD package. I’m also attaching a Unity build where you can control the different parameters of this project to recreate the effect. The testing steps are simple - turn on the project, press “Start” and then increase the “Group5” volume. (Here’s a video preview where you can see the desyncing the first time, and then everything working fine the second time).
That sounds about right! Good to hear the issue is solved and sharing your solution. Thank you for the project and the video. I will leave it for now, however, it will be useful if you encounter any other issues for future reference.
If there is anything else we can assist with please do not hesitate to reach out!
