DOCTOR AUDIO / TECHNICAL AUDIO / 001
Before We Touch a Sound
A game audio implementation audit for inherited projects
Joining a game in production means inheriting its technical decisions. Audio triggers may be scattered across code, animations, prefabs and scenes, with inconsistent routing and incomplete documentation.
That was our starting point: fixing bugs, adding content and maintaining an audio system we first needed to understand. Changing individual sounds would leave the underlying dependencies unexplained.
We developed scanners, analyzed runtime behavior and established validation methods before making changes. This paper explains our process, what the tools do and what we verified in production.
TL;DR
- We start by mapping the existing audio implementation before changing individual sounds.
- Editor scanners catalog registered events, identify supported references in scenes, prefabs and code, and inventory imported and loose audio files. They also support guided remediation, which is separate from inspection.
- Recorded profiler sessions turn intermittent behaviour into event timelines that distinguish suspected causes from observed activity.
- Findings feed a living knowledge base and approved implementation patterns. Targeted corrections are checked against repeatable scenarios, with verification status based on the records actually retained.
Game audio implementation audit: the starting point
Most studios call us after several people have implemented audio over months or years. Sounds come from code, scenes, animations, effects and UI, and nobody holds the full picture.
Some sounds bypass the middleware and mix. Events lose their callers, calls point to missing events, and volume controls affect unexpected systems. Intermittent bugs are difficult to reproduce.
Before asking what sounds wrong, we ask what is actually there. Inspecting every scene by hand does not scale, so we start with a repeatable map of the implementation.
Why manual auditing fails
Opening scenes and inspecting audio components one by one can help with an isolated issue. It is a poor foundation for an audit of a production that changes every day.
It misses what is not visible.A scene hierarchy does not show every audio call in gameplay code, animations, visual effects or UI. The same event can be referenced from several systems.
It becomes outdated.A manually compiled list can stop matching the project after another merge. When the inventory is produced by repeatable scanners, the team can run it again against a newer version.
It struggles to distinguish suspicion from evidence.“This ambience might be duplicated” is not a reproducible finding. A recorded session that shows overlapping instances, their timing and their triggers gives the team a specific issue to investigate.
This is why we make the first deliverable a set of repeatable answers about the audio implementation, rather than a collection of isolated fixes.
Our method
The workflow has five connected phases: Map, Trace, Observe, Standardize and Verify. Findings and verified results feed the shared knowledge base.
01 · Map
What exists?
We begin with read-only inventories generated from project files. These cover the audio events, files, buses, volume controls, snapshots and scenes that can be identified by the tools available to us.
At this stage we use the scanners in inspection mode without applying their optional remediation features. This establishes a repeatable baseline; any retargeting or import-setting changes require separate review.
Output: a searchable inventory of the audio system, with enough structure to support later cross-referencing.
02 · Trace
What triggers each sound?
An event inventory only tells us what has been authored. It does not tell us whether an event is called, from where, or by which mechanism.
We cross-reference authored events against the references the tools can inspect, including supported scene, prefab and source-code usages. Coverage is not universal: reflection, dynamic string lookups, Timeline and Animation Events are among the known blind spots. Runtime analysis complements the static inventory.
This exposes two useful classes of mismatch: events with no identified callers and references to events that are no longer present. Neither automatically means “delete this.” They become review candidates, with their context attached.
Output: a traceable relationship between an event, its references, its triggering mechanism and its routing.
03 · Observe
What actually plays?
Static scans describe what the implementation appears to be configured to do. Runtime captures show what happens during a play session.
We record profiler sessions and inspect event activity across time: starts, stops, pauses and overlapping live instances. When testers can mark the moment something feels wrong, we align those markers with the profiler data instead of trying to reconstruct the session from memory.
Some questions can only be resolved here. Is a loop starting again during a scene transition? Do two instances overlap? Does a sound continue during loading? A timeline turns those questions into inspectable behaviour. For a middleware-specific example, see the FMOD Studio profiling documentation.
Output: a runtime record associated with a reproducible test sequence and the affected event or system.
04 · Standardize
How should new sounds be implemented?
After mapping the existing variations, we define a limited catalog of implementation patterns for the core game. Examples include a 3D looping emitter, a one-shot triggered from an animation, a UI sound and an area ambience.
Each pattern describes its intended use, its required event and object configuration, and the checks that must pass before it can be created. The sound creation tool can then apply an approved pattern consistently.
This does not mean rewriting the whole project. New work follows the catalog; older implementations are migrated when a change is justified and safe.
Output: a reusable set of recipes and validators that prevents implementation drift.
05 · Verify
Did the correction work?
A fix is not complete merely because a scene looks correct in the editor. We revisit the relevant scenario and, where available, compare a new profiler capture with the original evidence. Missing follow-up records must be reported rather than implied.
The knowledge base should record what changed, how it was tested, what the retained evidence confirms and which project version was checked. If a follow-up reveals another dependency, the finding feeds back into the mapping process.
Output: a documented result linked to a test and a specific verified version.
One loop, one knowledge base
The inventory, trigger map, runtime observations, implementation patterns and verification records all belong to the same living reference. Its purpose is operational: an audio specialist joining the project should be able to understand an existing system without relying on who happens to remember how it was built.
Read First, Write Last. Use the scanners in inspection mode to establish the baseline. Review any guided remediation separately before applying changes.
Evidence from Production
Understanding how audio behaves at runtime requires more than listening for problems. Recorded profiler sessions allow us to trace event activity, investigate unexpected behavior and validate targeted changes against observable results.
Investigating unintended audio playback
Problem
Gameplay audio continued playing during loading transitions and cutscenes, while an ambient loop behaved inconsistently.
Detection
Profiler analysis revealed repeated start, pause and stop activity from legacy audio triggers. A newer emitter initially suspected of causing the issue was behaving correctly.
Correction
The findings guided targeted changes to scene-loading behavior and trigger logic, addressing the sources of unintended playback rather than replacing audio assets.
Observed Validation
A subsequent profiler capture confirmed silence during the affected transitions, a controlled ambience start and a smooth fade-in.
Based on a documented production investigation. Project identifiers, internal references and confidential technical data have been excluded.
Verified Technical Capabilities
Three implemented editor tools and two documented analysis methods support our approach to inherited game audio systems. The evidence below distinguishes implemented functionality from recorded production use.
| Capability | What it inspects | How it works | Available evidence |
|---|---|---|---|
| Event Scanner Implemented editor tool | Audio event references across scenes, prefabs and source code. | Catalogues registered events, traces their consumers, identifies unused references and supports guided remediation. | Implementation verified through source review. No retained scanner execution output. |
| Audio File Scanner Implemented editor tool | Imported audio clips, loose audio files, platform import settings and references. | Inventories audio assets, inspects import configurations and locates their usage across project resources. | Implementation verified through source review. No retained scanner execution output. |
| Sound Creation Validator Implemented validation tool | Event routing, spatialization, playback behavior, parameters and integration rules. | Compares event configurations against predefined recipes and reports passes, warnings and blocking errors. | Source review and retained batch-job records confirm execution of recipe checks. Individual blocking rules remain unverified by retained logs. |
| Mixer Routing Audit Documented analysis method | Bus hierarchies, routing assignments, snapshots, control structures and event outputs. | Reconstructs the audio routing structure by examining middleware project data. | Documented read-only production audit. Not a maintained standalone tool. |
| Profiler Timeline Analysis Documented analysis method | Runtime event activity, start and stop behavior, transitions and timing. | Interprets recorded profiler sessions, reconstructs event timelines and compares behavior across captures. | Documented production investigations, targeted corrections and follow-up validation records. |
Verification Workflow
For issues investigated through profiler captures, the affected scenario can be replayed and compared against the session that revealed the problem. A fix is only described as confirmed when the relevant follow-up evidence exists. The evidence used to identify a problem can also help confirm a targeted correction.
Compare event starts, stops, pauses and concurrent instances around the problem. After a proposed fix, record the same scenario again.
The accompanying timeline is an illustrative layout, not recorded profiler data. Public before/after figures from an independent synthetic demo remain pending.
What the evidence establishes
- Implemented capability
- Source review confirms implemented functionality. It does not automatically establish that each feature was executed in production.
- Recorded execution
- Retained batch-job results confirm execution of recipe checks. Individual blocking rules remain unverified by retained logs.
- Observed validation
- The retained follow-up profiler capture confirms silence during the affected loading and cutscene transitions, a controlled ambience start and a smooth fade-in under the tested scenario.
What we learned
A scattered implementation is not a lack of talent. It is what happens when many people work on audio over a long period without a shared map, shared tools and shared rules.
By building our own scanners and turning the findings into a living knowledge base, we can join a project in progress, understand what already exists, standardize how new sounds are implemented and verify targeted changes against the evidence available.
Practical trade-offs
Tooling has an upfront cost
The first days of an engagement may produce inventories and diagnostic tools rather than new sounds. This should be agreed with the studio at the start. The value is in making subsequent changes safer and easier to reason about.
Standardize forward; migrate selectively
Rebuilding every existing audio implementation at once can create more risk than it removes. We establish a clear pattern for new work, then migrate older content when it is touched, when it causes a bug or when a dependency makes the change necessary.
Preserve behaviour until there is a reason to change it
Inherited systems have constraints that are not always obvious. We keep existing behaviour and conventions where they still work. A wholesale rewrite needs a measured justification, not simply a preference for another implementation style.
Build patterns from the core game, not its exceptions
Prototypes, external modules and unusual features may follow different rules. We inspect the main implementation paths before deciding which patterns deserve to become standards.
Documentation needs a verification date
A technical page without a checked project version can become misleading as the production evolves. Every knowledge-base entry should identify when it was last verified and against which version. An older entry is a lead to investigate, not proof of the present state.
The tools do not make creative decisions
A scanner can show that a loop is playing near the edge of its audible range. It cannot determine whether that is an implementation bug, a mix decision or an intentional part of the experience. The tool exposes the behaviour; an audio specialist makes the call.
When This Applies to Your Studio
This approach is useful when an audio system has grown across multiple contributors and no single person can explain every implementation path. It is also useful when QA reports difficult-to-reproduce audio bugs, when an external audio team needs to join a project already in production, or when a studio is preparing an optimization pass or middleware migration.
The first working phase is aimed at producing a dependable inventory within the available coverage, a traceable map of triggers, prioritized findings, a small catalog of approved implementation models and a knowledge base the team can continue to maintain.
The exact scope and timing depend on the state of the project, access to its tools and build, and the systems that need inspection. An audit is a way to make those constraints visible, not a promise that every technical issue can be resolved immediately.
Questions We Can Answer
Why does Flutu publish technical whitepapers?
Around 99% of our projects are covered by strict non-disclosure agreements. That limits how much we can share through named case studies, project footage or internal production material.
Whitepapers give us a way to document how we have helped AA and AAA teams develop working methods, implementation standards and validation workflows, while respecting those confidentiality commitments. We focus on the methods, technical reasoning and evidence we can share without exposing protected project details.
This gives prospective partners a clearer basis for technical evaluation and due diligence: how we investigate systems, structure production work and check results. Each paper distinguishes what was implemented, what was observed and what remains unverified.
How do you audit game audio implemented by another team?
Start with read-only inventories of audio assets, middleware events and routing. Trace their references across game systems, compare that static map with runtime profiler captures, and document each finding against a known project version. Avoid broad implementation changes until the dependencies are understood.
How do you find sounds that bypass audio middleware?
Inspect engine-side audio sources and the places where sounds are triggered. Cross-reference those sources with the middleware inventory and routing map. Review the candidates in context before deciding whether they should be re-routed, replaced or kept.
How do you reproduce intermittent audio bugs?
Capture a repeatable play session and align its profiler timeline with QA markers or a documented test route. Compare event starts, stops, pauses and concurrent instances around the problem. After a proposed fix, record the same scenario again.
How do you standardize sound implementation across a team?
Identify the common implementation jobs in the core game, define a small catalog of approved patterns, and attach validation rules to each pattern. Apply those patterns to new work first; migrate existing content where it is safe and necessary.
How quickly can an external team become productive in an existing game?
There is no reliable universal timeline. Access to source files, builds, middleware, project conventions and existing documentation all affect onboarding. A repeatable inventory and trigger map can shorten the discovery process, but the schedule should be defined after reviewing the actual project.