Unity Workflow LibraryUWLAbout

Topic 11 · Audio

Audio architecture and engine choice

Choose built-in Unity audio, FMOD or Wwise, then run the polish pass in a fixed order.

Markdown version

This topic holds the reusable part of a full sound polish pass: engine choice, imports, mixing, 3D settings, voices, music, timing and mobile behaviour. Each rule sits on the page for its stage.

The three engines

Engine What it is Where the sound designer works
Built-in Unity audio AudioSource, AudioListener and Audio Mixer assets inside the Editor The Unity Inspector and the Audio Mixer window
FMOD for Unity The FMOD Engine plus a Unity integration package; events are built in FMOD Studio into banks FMOD Studio, with Live Update to a running game
Wwise Unity Integration A Unity plug-in library, C# bindings of the Wwise SDK, components and Editor windows The Wwise authoring application; SoundBanks are loaded in Unity
  • Built-in. An Audio Mixer is an asset holding a tree of groups with effects, sends, snapshots and ducking. The Manual notes the Web platform only partially supports Audio Mixers.
  • FMOD. The FMOD for Unity tutorial describes an event as a unit of sound content controlled from game code that can contain both audio files and playback logic, played in Unity by a Studio Event Emitter, with parameters set from code (SetParameter). Its setup wizard replaces the Unity listener with the FMOD listener and can disable Unity's built-in audio. Live Update connects FMOD Studio to the running game so mix changes are heard immediately; changes are kept only after the banks are rebuilt.
  • Wwise. The Wwise Unity Integration documentation lists SoundBank management, a Timeline integration, Spatial Audio (rooms, portals, reflectors, obstruction and occlusion) and an Addressables package.

Choosing

  • The engine is the user's call. The agent asks in the CLI before adding middleware, the same way it asks about the other stack choices on the Project setup page. Switching later means re-authoring every event and mixer.
  • Built-in is the default when the game's audio is clip playback with a mixer, and nobody on the team works in FMOD Studio or Wwise.
  • Middleware is worth it when a sound designer will own adaptive behaviour (parameters, transitions, randomisation) in a dedicated tool and wants to tune it live against the running game. Check each vendor's licensing terms before committing; the agent does not decide that.
  • Either way, the authored data rules of the Authored content topic apply: sound settings live in assets or banks a human can open, not in code.

The polish pass, in order

  1. Census before any edit: every bank row and clip, measured loudness of each imported clip (AudioClip.GetData, loudest 100 ms RMS; compressed or streamed clips per GETDATA-NEEDS-A-DECOMPRESSED-CLIP), clip lengths on frequent rows, and a Play census (voice starts, steals, pool-full share, master peak) with the listener where the game camera puts it.
  2. Imports (AUDIO-IMPORT-PER-PLATFORM), then gains from the imported clips (SET-GAIN-FROM-THE-IMPORTED-CLIP), on the import and memory page.
  3. Rows: fill silent families from clips already in the project, short clips on frequent rows, per-topic cooldown, pitch and volume jitter, priority (LONG-CLIP-ON-A-FREQUENT-ROW-IS-CUT on the voices page, NEW-GAIN-FIELD-IS-DB on the mixing page).
  4. Voices and 3D: per-device-class voice budget, priority stealing, rolloff from the listener distance (LISTENER-DISTANCE-SETS-THE-ROLLOFF on the spatial page).
  5. Mixer: limiter on master, ducking by routing (MIXER-GRAPH-FROM-CODE); end-of-run ring-out (END-OF-RUN-RINGS-OUT).
  6. Play census again against step 1, then a developer listen list: every clip choice and the mix are developer-listen-pending until a human hears them, and device memory and voice counts need a device measure.