# StudioEventEmitter Play/Stop issue when repeatedly called during the same frame **URL:** \ **Category:** Unity\ **Created:** [October 16, 2025, 6:43am UTC](https://qa.fmod.com/t/studioeventemitter-play-stop-issue-when-repeatedly-called-during-the-same-frame/23471 "2025-10-16T06:43:57Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![nzgreg](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/nzgreg/32/972_2.png) [@nzgreg](https://qa.fmod.com/u/nzgreg)\ **Post date:** [October 16, 2025, 6:43am UTC](https://qa.fmod.com/t/studioeventemitter-play-stop-issue-when-repeatedly-called-during-the-same-frame/23471/1 "2025-10-16T06:43:57Z")
hey fmod, we’re using some `StudioEventEmitter` components set to play OnEnable and stop OnDisable events to play some looping sounds in the background of a scene. Normally this is fine if plays and stops are not called on the same frame. However, we’ve hit a small issue when some other logic enables and disables the emitter several times during the same frame during scene startup and the sounds are looping / not oneshots. Our game logic actually activates/deactivates a hierarchy of gameobjects due to how the host/client networking framework works and some sound emitters are children under that hierarchy so they’re affected as various things start up. It’s also not really valid to shift to using Start/Destroy type events as the networking can start/stop any time, so OnEnable/OnDisable are appropriate events for us to use. Making a repro for the issue, it looks like the `StudioEventEmitter` doesn’t support doing a `Play Stop Play` immediately after each other on the same frame. The final `Play` does not work. If the instance is manually released (I tested adding this into the fmod PlayInstance code) then it plays ok, so it appears the calls aren’t being handled correctly somewhere either by the `StudioEventEmitter` with some protection or in the engine processing the events and invalidating the instance. This might be a known issue - apologies if I haven’t found it. Is there a workaround within fmod studio or using the `StudioEventEmitter` or do we need to wrap our usage in a coroutine/async or some other handler to avoid the repeated `Play Stop Play`? A repro for this is fairly easy - just make a script with a reference to a `StudioEventEmitter` and in a test method call `myEventRef.Play(); myEventRef.Stop(); myEventRef.Play();` and you should notice that the sound does not play. Thanks for any tips or advice on this little issue. I’m sure we can work around it but if there’s an obvious fix or you can repro and fix in the future then great. cheers, // greg ---
**Author:** ![cameron-fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/cameron-fmod/32/261_2.png) [@cameron-fmod](https://qa.fmod.com/u/cameron-fmod)\ **Post date:** [October 23, 2025, 4:09am UTC](https://qa.fmod.com/t/studioeventemitter-play-stop-issue-when-repeatedly-called-during-the-same-frame/23471/2 "2025-10-23T04:09:32Z")
So the problem is caused by the overlapping `Stop()` and `Play()`calls, the calls send commands to FMOD which then executes them the next time the FMOD System updates. In the `Stop()` function we also release the Event Instance but this appears to be happening after the `Stop()` but right before the second `Play()`, this then invalidates the instance as we attempt to play it. To work around this you can disable the “Allow Fadeout” on the Studio Event Emitter, this will clear the event instance as soon as it is stopped. ![Screenshot 2025-10-23 150808](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/9/9494954ccc8e3e639b0f3866321b803fb5ad5fdc.png) ---
**Author:** ![nzgreg](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/nzgreg/32/972_2.png) [@nzgreg](https://qa.fmod.com/u/nzgreg)\ **Post date:** [October 28, 2025, 8:52pm UTC](https://qa.fmod.com/t/studioeventemitter-play-stop-issue-when-repeatedly-called-during-the-same-frame/23471/3 "2025-10-28T20:52:43Z")
hi Cameron, thanks for confirming what I thought was going on on the fmod side processing the ordered sound events. We used a workaround with a coroutine (subclassed the fmod `StudioEventEmitter`) specifically to handle the unity enable/disable events, delaying the processing of the enable and cancelling it when the disable was called. Not a general purpose solution but did what we needed with starting/stopping basic loops when the gameobject becomes active with networking.