dspClockTime is out of sync after event instantiation?

Hey guys, I’m working on a synchronization game in Unity that requires precise knowledge of the time of the song that is playing, for event triggering and beat related things etc.

I’m using getDSPClock to get the dspClock time of the song event and it works relatively fine, but there’s this weird thing that when the event is first instantiated, the initial dsp time is delayed by around 2 seconds.

A simple example of what I mean - I have code similar to this in Update()

ulong dspClockTime;
ulong parentClockTime;
ChannelGroup musicChannelGroup;
eventInstance.getChannelGroup(out musicChannelGroup);
musicChannelGroup.getDSPClock(out dspClockTime, out parentClockTime);
var value = ((double)dspClockTime) / sampleRate;
Debug.Log("time: " + value);

and 0 is printed initially.

Then when I call (not starting the event, only instantiating it!)
eventInstance = RuntimeManager.CreateInstance(musicEventRef);

the block of code mentioned above starts logging “time: 2.1” or so. The values are somewhere around 2 seconds, and they are relatively random. Re-instantiating the event keeps adding time to the dsp clock.

I’d like to understand what’s happening, and how to deal with this issue and get precise time of the song.

One simple idea is that I guess I could just save this “delay” amount that the dspClock returns after event instantiating, and always decrease the time I get by this amount, to get the “real” timeline of the playing song.
But I’m not sure whether maybe there won’t be any extra delay in the dspClock once I actually start the event - maybe after I call start() on the event instance, the dspClock will again keep increasing or something for a while, without anything actually happening - so perhaps I should save the “delay”/dspClock time once the playback state returned by the event instance is “Playing”?

So basically, how should I get rid of the delay? When/how can I figure out what the final “delay” is that I should subtract from the resulting value, to get the real, precise time of the song playing?

Are you able to make use of Studio::EventInstance::getTimelinePosition instead?

It looks like the dspClock is being inherited from the channelGroups parent and there does not appear to be a way to stop that from happening.

When using the Studio API it is recommended to not dig into the Core API as it can cause some strange behavior.

Hello, thanks for the reply.

I could use getTimelinePosition but I was under the impression that dspClock is more suitable for precise rhythm related things, and that there could be issues with pausing/unpausing if using the studio api method (and perhaps other issues/possible stutter etc.) - I made this conclusion based off this post:

I’d be willing to not use the Studio API in this specific script if that helps, though I’d definitely like to use the studio api elsewhere. I have no idea how these things work on a lower level though so it might be a bad idea, but the event is just a song without any effects, so it might not be too problematic?

I’m also willing to just subtract the time in some fashion, but I’d like to reliably know what it is that I should subtract. It’s hacky, but I’m fine with it if it works.

It is fine to use the Core API along side the Studio API to create and use sounds, just not to dig into the the Studio side of things.

Depending on what you are wanting to do, you could also look into using Timeline Callbacks on an event.
FMOD_STUDIO_TIMELINE_BEAT_PROPERTIES & FMOD_STUDIO_TIMELINE_MARKER_PROPERTIES, there is also an example on using them in Unity: FMOD - Scripting Examples | Timeline Callbacks.

I see. Using timeline callbacks isn’t really an option for me, but thank you for the idea.

It seems like that the recommended options are to either stick with the Studio API getTimelinePosition call, or create my own sound solution for this one sound, fully inside of Core API, do I understand this correctly?

I’m sorry to insist about this, but would you explain what the issue is with simply subtracting the timeline position upon playing? If parent dsp clock time is reliably added upon initialization of the event, I can’t see much of a problem with just subtracting it. It would save me a lot of time to use a method like this, as I wouldn’t have to learn how to use the Core API for actual sound playing etc.

Yeah, basically.

It looks like both the clock times returned from getDSPClock will always be the same, although caching the initial value of the clock and subtract that from the new value returned should be fine.

Thanks a ton for your help!