This post is a follow-up to my previous "Improving the Wwise Unreal Integration" published last year. In that post, we apologized for the mistakes we made in previous versions of the Wwise Unreal integration and laid out our plans for the future. Here, we look back at the past year and talk about the current state of the Wwise Unreal integration.

Looking Back at the Past Year

The release of the Wwise 2022.1 Unreal integration marked the introduction of a new model called the Single Source Of Truth (SSOT). The short description of it is that the integration relies solely on what is present in the Generated SoundBank folder to "know" the Wwise project; it is the Single Source Of Truth. The new model also removed the automatic creation of Unreal assets for each Event and bus found in the Wwise project; now only the Wwise objects that are used in the Unreal project have Unreal assets. The Wwise Unreal plug-in's AkAudioEvent assets are the cornerstone of cooking, building and packaging. They are also the assets used to control the playback of sounds in Blueprints and C++ code.

Beta Feedback

As soon as the Wwise 2022.1.0 beta release became available, we started getting feedback from the community. As I am part of the Audiokinetic Support team, I am mostly aware of the constructive criticism that came through as Support tickets. 

Although everyone seems to agree the change to SSOT is a good step forward, it quickly became apparent that some tools to manage Unreal assets were missing. Current users of the Wwise Unreal integration did express that they missed the automatic synchronizing of assets that was part of the previous integration. They questioned our decision never to rename Unreal assets automatically, even when they rename an Event in Wwise. Although the new Unreal assets will keep track of what sound to play even when an Event is renamed in Wwise, the fact that the asset name does not follow the Event's name can become confusing.

Belated Launch

The amount of feedback we received during the beta period was substantial, and most of the feedback required some changes. This soon made it clear that we could not release the official version on time while integrating the feedback, so we belated the launch of Wwise 2022.1.0 to have a more complete and stable solution from the start.

Wwise Browser and Reconciliation

The feedback we received since the launch made our plans to introduce the unified Wwise Browser a clear priority. In case you missed it in the 2022.1.5 release, we introduced the change that merges the Wwise and WAAPI pickers into the Wwise Browser. Instead of having the Wwise Picker display what is present in the SoundBank metadata, and the WAAPI Picker display what is in the connected Wwise project, the Wwise Browser displays both and provides indications on the status of Wwise objects and their corresponding Unreal assets.

The 2022.1.6 version added the Reconcile button; a small UI update with tremendous implications for synchronizing Wwise objects and Unreal assets. It gives you the ability to synchronize some or all of your Wwise objects with a few clicks of the mouse. It is also possible to automate reconciliation by invoking the WwiseReconcileCommandlet after a SoundBank generation for example.

Multiple Sound Engine Version Support

Another change that was introduced to the integration is to allow projects to not have Wwise present in some circumstances. The initial motivation was to provide a solution for teams building a server version of their game where audio is unnecessary. This is what we call the “Null Sound Engine”; it allows building some project configurations without Wwise. Before this change, the SoundEngine was frequently loaded uselessly and unused.

With this ability to have more than one SoundEngine supported by a given version of the integration code, we have started adding modules for major versions of Wwise. This is why our current integration code works well with Wwise 2022.1.x and 2023.1 beta. The integration code detects the version of the Wwise binaries and uses the appropriate SoundEngine module to interact with Wwise. If the Wwise binaries for a given platform are missing, the integration will use the Null SoundEngine.

Asset Management in SSOT

Moving away from the Event-Based Packaging that was done by the Unreal integration in the past, we have given Wwise the ability to automatically generate SoundBanks; these are called Auto-defined SoundBanks, whereas manually crafted SoundBanks in Wwise are now called User-defined SoundBanks. While these can still be used for an Unreal SSOT project, they require an understanding of the Wwise asset management in our Unreal integration.

Legacy and Unreal IO Hooks

Input and Output (IO) Hooks are functions that read and write files to disk. Wwise's IO Hooks are called "default Streaming Manager" because that is what Wwise uses by default and it is expected that Wwise users may elect to use another tool to manage their IO. A good example would be a team using its own game engine and deciding to use the IO hooks of the game engine to load Wwise SoundBanks and streamed files. 

With the introduction of the EBP workflow in 2019.2.1, we started using the Unreal IO hooks when a project opted to use EBP. We kept the Legacy IO Hooks available for the teams that decided to keep using the legacy workflow.

The introduction of the SSOT workflow in 2022.1.0 made the use of the Legacy IO Hooks obsolete as all IO is now done using Unreal's IO. It is not expected that users of Unreal will override the IO hooks of the engine, and since the Wwise "default Streaming Manager" is optional we replaced it with Unreal's.

Wwise Memory and Unreal Memory

As part of the Wwise initialization sequence, the Memory Manager module is initialized to manage the memory required by the Sound Engine at runtime. That has always been the case in the context of a Wwise Unreal integration but what is loaded in that memory varies based on the model used (Legacy, EBP or SSOT). Back in the pre-2019.2 integration (aka Legacy), that is where the SoundBanks and streamed media files were loaded and played by the game. Their corresponding Event and SoundBank Unreal assets were loaded in memory allocated by Unreal Engine. 

Since introducing the EBP workflow in the 2019.2.1 version, we have started using the memory allocated by Unreal to store the media encapsulated in assets. One of the painful lessons we learned was that Unreal assets are great when it comes to cooking and packaging a project, but they are not reliable containers for media. The SoundBanks in EBP did not contain the media, only the Event and Structures as authored in Wwise. They were loaded in the memory managed by Wwise.

Starting with the introduction of SSOT in Wwise 2022.1.0, Wwise media is not stored within Unreal assets anymore. The Event assets now only contain information about the Wwise Event; its location on disk and the different IDs that allow Wwise to find them. As for EBP, the SoundBanks for SSOT do not contain media and are loaded in memory managed by Wwise. When an Event needs to be loaded, its media-less SoundBank is loaded in Wwise memory while the media file is loaded in Unreal memory. The memory location where it gets loaded is then passed to Wwise via either the LoadBankMemoryView or LoadBankMemoryCopy SDK functions. The most memory-efficient choice is to use Auto-defined SoundBanks as they get loaded by LoadBankMemoryView, thus avoiding duplication of memory. 

This memory allocation scheme is the most efficient but it comes with a drawback: the Wwise Profiler can only monitor the memory allocated by Wwise. This means that the Wwise Profiler reports the memory used by the media-less SoundBanks but not the Unreal memory used to store media. This is why we gathered Wwise media memory counters in Unreal under the Wwise/WwiseMemory stat category, allowing us to use the Unreal stat command to track media allocations.

On the Horizon

One of the improvements we are working on is to update the packaging options for Wwise data in an Unreal project. As it is currently difficult to package assets that are not UAssets in Unreal, we know we need to improve in that area. In particular to better support the Zen Loader and Store, DLCs, localizations, the new Virtual Assets, and feature updates.

Another item that is coming soon is the release of our Unreal Gyms to GitHub. We have created our Gyms framework during the development of the SSOT workflow to automate testing as much as possible. We have also started using this framework to reproduce issues that are reported to Support. When we do develop a new gym in the course of an investigation, it gets added to our collection and strengthens our future testing.