Discrepancy between Audio.dspTime and state->currdsptick in Native Plugin?

Audio & Video
1

Hi All,

This pertains to the Native Plugin SDK. I downloaded it here

and was extremely impressed by how easy it was to get going. However, I’m seeing a discrepancy between the Audio.dspTime value and the current sample tick I receive in the plugin process callback. To be fair I would expect a discrepancy of some sort, but what I see is wildly inconsistent and not grounded in reality.

If I open the midisynthesizer scene provided in the SDK repository (replacing their DLL with a debug DLL I build from source), I can see that MIDI events are sent along with a sample position. I’ve added the following code to MidiSynthPhrase.cs for debugging.

    void Update()
    {
        if (Input.GetKeyUp("f"))
        {
            ulong sR = (ulong)AudioSettings.outputSampleRate;
            ulong samplePos = (ulong)(sR* AudioSettings.dspTime);
            Debug.Log("AudioSettings.dspTime is " + AudioSettings.dspTime);
            Synthesizer_AddMessage(samplePos, 0x7F4790); 
        }
    }

So when I press the “f” key, I send a MIDI message and print the time in seconds to the console. Then, on the plugin side I compute the following in the process callback

double dSeconds = (double) state->currdsptick / (double) state->samplerate;

And, sure enough, I do see pretty much the same values (they may be off by a few hundredths of a second, but that’s fine by me.)

However, if I create a new project/scene and add the synthesizer plugin (which I build from source) to an audio mixer group, the same code yields wildly different results. Sometimes the difference will be a few seconds, sometimes it will be a full minute.

This frankly seems impossible, especially because I’m using a breakpoint in the C++ code to check the time on that end and it gets hit instantly after I release the “f” key (not 52 seconds later, which is what my most recent test yielded.)

To sum up, I get consistently accurate timing in their sample project, but in my own projects the timing is way off (using the same plugin binary). Sometimes it starts out accurate, but it seems to drift over time. I’ve checked the audio settings - both are the same (latency is set to “Good Latency”), and indeed I do hit that breakpoint very fast. It’s just that the two values (Audio.dspTime and state->currdsptick) seem completely out of sync with one another.

Howe can this be? Is there something I need to do in my project? I guess I’m ok with using their project as a starting point, but that doesn’t seem sustainable…

Any help you can provided is extremely welcome.

Thanks,

John

2

I think I’ve found out the cause of the delay, though I still see a discrepancy in the times when using the demo synth plugin in one of my projects vs. the SDK demo project.

Everything stays dead on until I use a breakpoint in C++ to check the timing - if I store the values up until I hit the breakpoint I see that they’re accurate, but after releasing the breakpoint my project the Audio.dspTime value gets behind the currdsptick value.

This isn’t he case in the demo project - I just held the breakpoint for a few minutes and when I released it everything was perfectly in time. It’s as if holding the breakpoint in my project allows the audio thread’s sample value to advance, but not the UI thread’s. Is there some function I need to call in C# to sync the two up?