Using EventInstance captured from START_EVENT_COMMAND callback

Unity
,
1

Hello,

I am trying to get an event instance from a START_EVENT_COMMAND callback and then use it later on in managed code to update params/attach it to a transform.
The callback seems to work without complaint, but I’m getting an assert when trying to get the description of this event instance later on:

[FMOD] assert : assertion: 'inst->mHandleBits != 0' failed

Here is how my callback looks:

[AOT.MonoPInvokeCallback(typeof(EVENT_CALLBACK))]
		static RESULT HandleCallback(EVENT_CALLBACK_TYPE type, IntPtr instancePtr, IntPtr parameterPtr)
		{
			FMOD.Studio.EventInstance instance = new FMOD.Studio.EventInstance(instancePtr);
            IntPtr callbackInfoPtr;
            FMOD.RESULT result = instance.getUserData(out callbackInfoPtr);

            if (result != FMOD.RESULT.OK)
            {
                UnityEngine.Debug.LogError("FMOD Callback error: " + result);
                return result;
            }
            else if(callbackInfoPtr != IntPtr.Zero)
            {
                GCHandle callbackHandle = GCHandle.FromIntPtr(callbackInfoPtr);
                StartEventData callbackInfo = (StartEventData)callbackHandle.Target;

                switch (type)
                {
                    case FMOD.Studio.EVENT_CALLBACK_TYPE.START_EVENT_COMMAND:
                        {
                            if(parameterPtr != IntPtr.Zero)
							{
                                try
								{                   
                                    FMOD.Studio.EventInstance param = new FMOD.Studio.EventInstance(parameterPtr);
                                    if(param.isValid() && param.hasHandle())
									{
                                        callbackInfo.Triggered = 1;
                                        callbackInfo.StartedInstance = new EventInstance(parameterPtr);
									}
								}
                                catch(Exception e)
								{
                                    UnityEngine.Debug.Log(e);
								}
							}
                        }
                        break;
                    default:
                        break;
                }
            }
            return FMOD.RESULT.OK;
		}

And here is the call where I get the assert (this happens later down the line in a monobehaviour update where I wait for the “Triggered” to be set to 1):

ignitionCallback.Data.StartedInstance.getDescription(out var desc);

What am I doing wrong? Or is there a different way I should go about updating an instance that was started this way?
If needed I can provide more code than this.
Also, interestingly, using the runtime manager to attach this instance to a gameobject does not produce any errors.

Thank you.

2

I think I might need a little more context to figure out what’s going on here- can you please share a code snippet for what’s happening when you call setCallback?

3

Sure,

the callback is wrapped in a class and set when that class is constructed, like so:

		public FMODStartEventCallback(EventInstance eventInstance)
		{
            data = new StartEventData();
            callbackHandle = GCHandle.Alloc(data, GCHandleType.Pinned);

			actualCallback = new FMOD.Studio.EVENT_CALLBACK(HandleCallback);
			eventInstance.setUserData(GCHandle.ToIntPtr(callbackHandle));
            eventInstance.setCallback(actualCallback, EVENT_CALLBACK_TYPE.START_EVENT_COMMAND);
		}

Another class then later asks this wrapper class for the data from the callback, which is defined like this:

    [StructLayout(LayoutKind.Sequential)]
    public class StartEventData
	{
		public EventInstance StartedInstance;
        public int Triggered;
	}

the returned EventInstance also returns true on isValid and hasHandle, but trying to get the description fails as mentioned above.

4

Thanks for the extra info- it seems there is a problem with the underlying API and the START_EVENT_COMMAND callback isn’t returning a valid handle to the new EventInstance, even though isValid and hasHandle are both somehow returning true.
I’ve written up a bug report for the dev team to look into.

5

Thanks for looking into it!
We’ll try to work around the issue for now.