Views: 24
Introduction
I am currently handling the technical audio implementation, pipeline management, and sound design for an ongoing indie title, Mardow. Recently, I encountered an issue where environmental audio and core mechanical sounds were dropping out entirely during scene transitions.
Since Mardow is still in early development, I’m keeping this breakdown focused on the technical implementation rather than gameplay footage. It’s a bit too early to share the visuals publicly, so I’ve focused this case study on the “under-the-hood” work; which, in my experience, is often where the most critical audio design challenges live.
When I attempted to recreate this issue for documentation, the ambiences seemed to work perfectly… Typical. But I did take some screenshots during debugging!
Debugging the Issue
To understand the source of the audio dropouts, I captured and analysed the Wwise profiler data during a transition from the outdoor farm scene to the interior house scene, and back again.

The logs revealed a two-part failure in the audio lifecycle:
-
Scene Exit (0:00:16.277 – 0:00:16.618): Upon exiting the farm, the system logged an
Event ID not founderror forPlay_AMB_Farm_Day. This was immediately followed by a couple of failed bank unload requests, where Wwise could not locate theFootstepsorMain_Ambiencebanks in memory. It was trying to clean up audio files that hadn’t properly loaded in the first place. -
Scene Re-entry (0:00:20.096 – 0:00:29.589): Upon returning to the farm, the
Play_AMB_Farm_Dayevent triggered correctly, but this initiated a massive 9.5-second stall in the audio pipeline. During this period, the profiler showed constantMedia updatednotifications as the engine struggled to stream individual audio files (including wind and bird/insect layers) directly from the disk. The ambience did not resume aPlayingstate until 0:00:29.589. The game was essentially waiting until the last possible second to load the audio files from the disk.
The Unity debug logs provided the final piece of the puzzle, exposing a fundamental race condition in the asset-loading hierarchy (Unfortunately, I have no screenshot of this).
The console confirmed that the AkEvent component on the OutsideSpawn GameObject was attempting to post Play_AMB_Farm_Day during the AkEvent:Start() lifecycle method. Because both the event trigger and the SoundBank loading were firing during the same Start() phase, the system was attempting to play the sound before the SoundBank had successfully registered in the engine’s memory. This conflict resulted in the Post Event failed error and the associated failure to verify the Event ID.
Upon further inspection of the OutsideSpawn GameObject, I could see the issue:

The root of the ambient audio dropout was clearly visible in the component configuration of the OutsideSpawn GameObject. Both the AkBank and AkEvent components were set to execute on Start. Because Unity’s Start lifecycle method does not guarantee the order of execution between separate components, the event trigger was attempting to fire before the SoundBank had finished registering its data, resulting in the Event ID not found errors captured in the profiler logs.
Resolving the Issue
To resolve these implementation failures, I focused on cleaning up the object hierarchy and restructuring the audio initialisation pipeline within Unity to ensure asset reliability.
Looking at the component setup above, the OutsideSpawn object was cluttered with audio components that were competing for resources. To clean this up, I moved the ambient audio components off the OutsideSpawn object entirely and onto a dedicated Audio_Ambiences object. This separation of concerns made it much easier to manage the lifecycle of these assets without them interfering with other spawn logic.


Figure 3: The new Audio_Ambience object in the Unity Project Heirarchy (left) and the associated components within the Unity Inspector view (right).
On this new object, I updated the AkBank component to load on Awake. By shifting the bank registration to an earlier lifecycle phase, I ensured the bank is fully loaded and ready to process incoming calls before the AkEvent component executes.
For the footstep audio, the issue stemmed from the bank’s reliance on a scene-based load/unload cycle. During transitions, the bank was set to Unload On: Destroy, and the persistent Player object failed to re-verify the assets upon re-entry. I kept the footstep SoundBank tied to the Player object, but I changed it to Unload On: Nothing. This decouples the core mechanical assets from scene-specific cleanup, effectively eliminating the transition silence and providing a stable, consistent audio experience. Realistically, there is no need for the Main_Ambience or Footstep SoundBank(s) to be unloaded between transitions at this stage, so this fix keeps the pipeline solid for the rest of the development build.

Leave a Reply