Stop immediate throws warnings on programmer sounds unity

Unity
1

EventInstance.stop(FMOD.Studio.STOP_MODE.IMMEDIATE);
EventInstance.release();

Throws this warning:
[FMOD] EventInstance::flushReleaseQueue : Event instance has programmer sounds pending release, update thread will be bloocked until programmer sounds are released.

If I allow fade out, then I don’t get the warning. But if the sound is paused, then it never gets released.

2

Studio::EventInstance::release marks an event instance to be released as soon as it is stopped. We therefore generally recommend calling Studio::EventInstance::release as soon as you start the event instance, so that it can be cleaned up immediately as soon as it finishes playing. Since you are only calling Studio::EventInstance::release after the event has stopped, FMOD is warning you that the event’s sounds cannot be released because the event has not been marked for release.

If you allow an event to fade-out when stopping it, it may take some time to stop. Since you are calling Studio::EventInstance::release immediately after calling for the event to stop, this means that the event is being marked for release before it finally stops, thus preventing the situation that causes the warning.

Pausing an event does not change the event’s playback state, so playing event that is paused still has the “playing” playback state, not the “stopped” playback state. This is intentional, to allow paused events to be un-paused and resume playing at a moment’s notice.

In other words, it sounds like you’re experiencing the expected behavior.

3

Thanks for the detailed information! I didn’t know that release had to be called before stop. That’s really good to know. It’d be awesome if you guys could add the requirement to release before stopping to the documentation. Maybe I missed it, but I don’t see it here:
https://fmod.com/resources/documentation-api?version=2.0&page=studio-api-eventinstance.html#studio_eventinstance_release

4

Release doesn’t have to be called before stopping, the event, it’s just good practice, as it ensures that an event ceases taking up resources immediately upon stopping instead of continuing to take up resources until release is called.

Good idea! I’ve a task to document this information to our feature/improvement tracker.