Unreal Engine FMODAudioComponent Accumulation & Performance

Unreal Engine
1

FMOD Version: (2.03.06)

Unreal Version: (UE5.5)
Platform: Mobile/Android/Meta Quest

Hello! We are experiencing large spikes in CPU usage on the Game Thread, traced specifically to FMODAudioComponent updates. These spikes occur even when:

  • No obvious sounds are playing

  • No gameplay events are firing

  • The player is idle

Profiling in Unreal Insights shows hundreds of FMODAudioComponents (200–500) alive simultaneously, each costing a few microseconds, which accumulate into significant frame-wide CPU time.

FMOD itself does not appear to be performing heavy DSP work — most of these event instances appear to be virtualized voices, but their corresponding Unreal FMODAudioComponents remain attached, active and continue to tick indefinitely.

Unreal Insights consistently shows:

FMODAudioComponent

Count: ~200–500

Incl: ~1.2–2.0 ms

Excl: ~1.0–1.8 ms

Even when no audible FMOD events are expected.

Severe spikes in UpdateComponentToWorld

FMODAudioComponent instances appear under:

UpdateChildTransforms → UpdateComponentToWorld → FMODAudioComponent

Components persist even if event audio is silent or virtualized

FMOD DSP time is extremely low → expected if voices are virtualized.
However, their Unreal components remain alive and continue ticking.

Occurs across many actor types

Not isolated to a single weapon or enemy type.
Seen in:

  • Sounds called by Gameplay Cues

  • Sounds called directly on code.

  • Apparently, with sounds called by the “UFMODBlueprintStatics::PlayEventAttached” function

Environment Details

  • Game uses object pooling for most enemies.

  • Many sounds use PlayEventAtLocation or PlayEventAttached (in all cases we keep the bAutoDestroy bool as “true”.)

  • Some events have long tails, reverb zones, or multi-instrument layering

  • Some weapons fire rapidly (machine gun), causing many simultaneous one-shots

  • Voice stealing/polyphony limits enabled for certain events

Observed Behavior

  1. Each FMOD event instance spawns a new FMODAudioComponent (expected)

  2. Many of these events are virtualized by FMOD

  3. The underlying FMODAudioComponent persists:

    • It does not automatically destroy itself

    • It continues to tick every frame

    • It stays in the world even if the actor that triggered it is returned to a pool

  4. Over time, the number of active FMODAudioComponents grows:

    • 100+

    • 200+

    • 500+ in extreme cases

  5. Unreal continues to run transform updates and tick logic for every FMODAudioComponent

  6. CPU cost scales linearly with number of components

  7. Eventually, frame times spike significantly on Oculus Quest

Hypotheses (What we suspect might be happening)

Hypothesis A: FMOD virtualized voices do not destroy their Unreal components

FMOD virtualizes voices when polyphony limits are reached, or when volume falls below audibility thresholds.
However, the Unreal UFMODAudioComponent persists and continues ticking even if:

  • Audio has been virtualized

  • No DSP processing is occurring

  • The event is effectively silent

    This leads to hundreds of active components whose only cost is transform ticking.

Hypothesis B: PlayEventAtLocation and PlayEventAttached create short-lived components with long auto-flush times

If the event contains:

  • Long reverb tails

  • Sustain points

  • Loop regions

  • Multi-instrument delays

  • Attenuation curves with slow fade-outs

…then FMOD keeps event instances alive longer than expected.
Even if the sound is inaudible, the Unreal component may persist until FMOD fully releases it.

Hypothesis C: Interaction with Unreal actor pooling

When pooled actors “die”:

  • They are not destroyed, so EndPlay() is not executed

  • Any attached FMOD event instances are not stopped

  • When actors respawn, new audio components are added on top of old ones

  • Over time this produces a **component leak
    **

Hypothesis D: Virtualized voices re-activate or never fully stop

Because FMOD tries to preserve event state for unvirtualization, it may keep instances alive longer than expected, and Unreal components don’t auto-destroy.

Said that maybe you can give us some answers fo teh following questions:

  1. Clarification on the expected lifecycle of virtualized event instances in Unreal

    • When an FMOD event becomes virtualized, should its Unreal AudioComponent remain active?

    • Is Unreal responsible for cleaning up virtualized events manually?

  2. Recommended way to ensure FMODAudioComponents are fully released

    • Should we manually call Stop() or Release() on all FMOD event instances?

    • Is there a recommended cleanup hook?

  3. Whether FMOD provides callbacks for virtualization state changes
    e.g. “OnVirtualize”, “OnUnvirtualize”
    so we can destroy components earlier.

  4. Guidance on pooling compatibility

    • Are there known issues when pooling actors that create FMODAudioComponents?

    • Should we manually flush events when returning actors to the pool?

  5. Verification that FMODAudioComponent ticking thousands of virtualized instances is intended
    Or whether this could be a bug.

We very much appreciate your help!

1 Like