Scene Audio Debugger
Playing FMOD events, visualized where they actually happen in Unity.
DOCTOR AUDIO · UNITY + FMOD · EDITOR TOOLING · WHITEPAPER · VICTOR HIME · UNITY PLAY-MODE DIAGNOSTICS
When a sound is missing, doubled or in the wrong place, an event list and a level view each tell only part of the story. The Scene Audio Debugger brings the two together.
Built by Flutu and used in production, this Unity Editor tool reads live FMOD Studio instances and displays their positions, playback state, output level, ranges and identifiable source objects directly in the Scene view.
By joining live middleware state with Scene context, the debugger helps the team distinguish playback, placement, ownership and mix-routing questions before making changes.
TL;DR
- 01
See the middleware state. Enumerate active FMOD instances rather than relying on a scan of Unity emitter components.
- 02
Locate the sound. Draw 3D events at their FMOD positions, with range discs; locate 2D triggers when source objects are known.
- 03
Inspect the source and state. Read playback flags, event-level metering, parameters and ownership through a Scene view overlay.
- 04
Connect scene inspection and profiling. Inspect live instance state and event-level metering, then combine them with recorded profiling and mix checks.
The problem: an event list without a world
“The waterfall is silent near the bridge.” “Two river loops are playing.” “Menu music survived the scene transition.” These are illustrative audio bugs that require both playback information and spatial context.
Component gizmos and log messages only cover the call paths they were written for. The debugger instead queries the state FMOD currently knows about.
The architecture: FMOD state and Unity context
The tool reads instances from the FMOD Studio system, not from a list of placed emitters. This includes instances started by code or pooled managers when they are alive at sampling time.
The tool runs in Unity Editor Play Mode and reads FMOD listener 0. Multi-listener projects require an extended listener mapping.
Real playback
Displays playing instances, not just assigned event assets.
Actual FMOD coordinates
Uses instance 3D attributes, which can differ from a GameObject transform.
Object provenance
Looks up identifiable emitters, attachments and pooled instance owners.
Editor-only
Source files live in an Editor folder and are excluded from player builds.
What appears in the Scene view
A 3D event is drawn at its FMOD coordinates, with minimum and maximum distance discs. A 2D event has no FMOD world position: when its triggering GameObject is known, a square marks that source and a dotted line points toward the listener.
Marker colors follow the project's event-folder convention:
- SFX
- Ambience
- Music
- VO
- UI
What the marker tells you: event name, instance output level, distance to the listener and playback-state flags, including virtual, paused or stopping.
Overlay and playback ownership
The Scene view overlay joins filtered instances with the details of one selected instance. The controls cover 2D/3D visibility, virtual events, labels, distance discs, listener lines, name search and a maximum display distance.
Playing instances
2D events without a world source stay in this list. Positioned instances are available in a separate expandable group.
Filters: 3D / 2D · Virtual · Labels · Min/max · Name · Distance
Selected instance
Event path · Playback state · Event output level · Source GameObject (if identified) · Local and global parameters
Selecting a row frames the corresponding location in the Scene view.
Unknown ownership is still useful diagnostic information. A 3D sound can be drawn without a source; a 2D sound with no known source remains in the overlay rather than appearing at a fabricated coordinate.
Sampling cadence and signal boundaries
The sampler separates slow-changing event catalogs from rapidly changing instance state. The refresh intervals below define the inspection cadence; their Editor CPU and metering costs should be checked against each project's scale.
| Data | Refresh | Notes |
|---|---|---|
| Loaded-bank event catalog | 2 s | Paths and 3D classification |
| Scene emitter-component discovery | 1 s | Unity emitter references |
| Live instances, state, 3D attributes, ownership, meter and listener | 50 ms | Approximately 20 inspections per second |
| Selected-instance parameters | Overlay repaint | Current local and global parameter values |
The list is sorted by measured instance level. This makes prominent events easy to find, but the value is neither final output loudness nor a guarantee that the player can hear the sound.
From playback state to a debugging decision
We use the debugger to answer three production questions: what is actually playing, where the audio engine places it, and which Unity object can be associated with it. Those answers guide the next check in FMOD, scene logic or the mix.
Playback visibility
Inspect live FMOD instances, 3D positions, playback flags and event-level metering even when playback originates from code rather than an emitter.
Source attribution
Connect instances to Unity emitters, runtime attachments or pooled managers when ownership data exists. Unknown sources remain explicit rather than being assigned invented coordinates.
Validation and cost
Verify positions and state against known test cases, measure Editor overhead under representative instance counts and capture FMOD profiler sessions when event history matters.
For the audit workflow that connects scene inspection with recorded profiler evidence, read Before We Touch a Sound.
Companion: Sync Scene View to Game Camera
The companion utility copies the Game Camera framing into the Scene view during Play Mode so audio markers can be compared against the player's view. It restores the Scene camera settings when synchronization stops. It does not change the live FMOD data model.
Applying the method to another project
A useful first version does not require rebuilding FMOD's profiler. It requires a reliable connection between live instance state and world-space context.
Enumerate instances from FMOD. Traverse loaded banks, event descriptions and live instance lists instead of searching only for components.
Sample at separate rates. Refresh catalogs less often than instance state; check impact before enabling broad metering.
Draw FMOD coordinates. Visualize actual instance 3D attributes and show 2D source references only when known.
Map every trigger path. Include emitters, attached instances and the project's playback manager. Expose lookup failures explicitly where possible.
Validate against known cases. Compare a placed loop, a code-triggered 2D event, moved 3D position, paused/virtual instance and source-less music.
Questions We Can Answer
Why does Flutu publish technical whitepapers?
Most production work is NDA-covered. Whitepapers let the team document tools, decisions and technical boundaries without exposing confidential project data.
Can I see FMOD events started from code?
Yes, when an instance is alive during a sample and belongs to a loaded bank. The debugger enumerates FMOD instances rather than depending on Unity emitter components.
Why can an event be drawn away from its GameObject?
Its FMOD 3D attributes may differ from the object's transform, especially when it was manually positioned or not attached to the moving GameObject.
How do I identify the object that started a sound?
The tool maps FMOD instances back to scene emitters, runtime attachments and a project-specific sound manager pool. If none matches, the source remains unknown.
Why might a marker show level while the game is silent?
The debugger meters the event's head DSP, before downstream buses, VCAs and snapshots. Check the complete signal path and listen to the final mix.
How do the debugger and FMOD Profiler work together?
This view shows current state without recorded history. Profiler captures are needed for precise event timing and short-lived playback that may fall between samples.
Related technical service: Technical Audio at Flutu · Doctor Audio research library