Transceiver event not stopping

Hello everyone.

The problem is this: it would appear that if you try to stop an event containing a transceiver set to receive, it will get stuck at ‘STOPPING’ until all sources that may be transmitting on that channel have fallen completely silent, even if either/both transceivers’ Level is set to -∞ (which doesn’t stop the dB meter on the transceiver moving up and down either). This occurs in FMOD Studio as well as in-game in Unity.

Is this behaviour intentional, and if so, how can one stop a receiving event without having to pause/stop the transmitting source events?

Thank you in advance for your time.

This is by design. What is happening is the stop() command is allowing fade outs so as long as there’s some kind of signal coming out of the event (eg. from a reverb or delay effect, or a transceiver) then it will be in the “Stopping” phase.

If you wish the transceiver receiving event to stop but the transceiver sending event to continue, then you need to call FMOD_STUDIO_STOP_IMMEDIATE in the stop() function on the transceiver receiving event.

If you wish all transceiver receiving events to stop at the same time, then you should call stop() on the transceiver sending event.

https://www.fmod.com/resources/documentation-api?version=2.0&page=studio-api-eventinstance.html#studio_eventinstance_stop

https://www.fmod.com/resources/documentation-api?version=2.0&page=studio-api-eventinstance.html#fmod_studio_stop_mode

Hello and thank you for the swift reply!

I understand the thinking behind this behaviour, but I cannot grasp why turning the transmitting transceiver’s Level knob all the way down will not let the receiving event die in peace, since no sound is being transmitted/received? Essentially, this means that the Level knob currently is only half-functional, in that it only lowers the user-audible output, but nonetheless behaves as if the transceiver is still transmitting/receiving anything other that silence. Why is that?

Finally, what happens if the receiving transceiver is in a nested/referenced event?

The reason the event doesn’t release automatically when you move the level to -oo dB is because events don’t release naturally (ie. without stop() being called on them) if there is audio input going into an effect in a tracks effect chain. When you set the level to -oo dB, that is for the output of the effect, the input is still receiving audio, even if that audio is not audible.

I will add the ability to release the tranciever effect if the level is set to -oo dB as a feature request to our tracker. We will look into it for a future release.

In regards to nested/referenced events, they behave exactly the same way as a normal event would. For as long as the event instrument is triggered and the parent event is playing, the transceiver will play the audio it receives.

Hello FMOD Support Team,

I am writing to share my insights regarding this frustrating architectural limitation involving the FMOD Transceiver effect (configured as Receive) when integrated into Unreal Engine via Blueprints.

As follows from this topic, there is a known issue where an Event Instance containing a Transceiver (Receive) effect on its Master Bus or an Audio Track completely ignores standard Blueprint commands like Stop, Event Instance Stop, or even Destroy Component.

If I understand correctly, the Stop node always invokes a soft stop (FMOD_STUDIO_STOP_ALLOWFADEOUT)under the hood. Since the Receiver continuously pumps a live DSP audio stream from the memory, the FMOD sound engine gets permanently stuck in the STOPPING state. As a result, the event with the Receiver never transitions to the STOPPED state, leading to memory leaks as these instances accumulate during gameplay.

While searching for solutions on the forum, I encountered advice recommending the low-level STOP_IMMEDIATE command. However, this solution is far from ideal. First and foremost, the standard Blueprint integration simply lacks a native node or wrapper to execute a hard stop (IMMEDIATE) for a specific, single event instance. Furthermore, even if a hard stop were accessible via Blueprints, it would instantly cut off the audio signal, making it impossible to achieve a smooth fade-out using AHDSR modulation. This renders it useless for gameplay scenarios that require natural sound attenuation (for example, dynamic ambience “leakage” through doors or windows that need to fade out smoothly using an AHDSR modulator on the Master Fader).

Currently, developers are forced to rely on inconvenient workarounds: either routing each instance to separate temporary sub-busses and calling Bus Stop All Events on them, or setting up internal parameter automation combined with Command Instruments inside FMOD Studio. These methods severely overcomplicate the project, especially when you need to simultaneously manage multiple unique copies (such as dozens of window and door sound emitters across a level, each needing to fade out independently).

I earnestly request that you add direct control over the Receiver’s stream in future updates of the FMOD integration for Unreal Engine. For instance, it would be incredibly helpful to have a dedicated Blueprint node that allows stopping and releasing the incoming stream of each specific Receiver from memory whenever the event it resides in is stopped or destroyed.

Regarding individual instance destruction: I would highly appreciate a feature that guarantees the absolute destruction and memory unload of a specific instance containing a Receiver, while still allowing the AHDSR envelope on the Master Bus to cleanly execute its Release phase.

Thank you for your time and continued support. I look forward to hearing your comments on this matter.