The introduction of the Event-Based Packaging (EBP) asset management workflow in Wwise 2019.2.1 was welcomed by the Wwise-Unreal developer community as an elegant solution for managing Wwise assets in Unreal. However, some teams encountered production blocking bugs while transitioning from the classic SoundBank workflow. While we’ve been working on resolving bugs reported by developers making the jump to EBP, we’ve also been planning and implementing the changes to match the stability of working with SoundBanks. 


We are humbly requesting affected teams to accept our apologies for the delays and inconvenience caused by the inconsistencies of the feature at launch. We’d like to share our current plans from the Game Engine Integration team to give you a glimpse of what to expect in the future. Thanks for your patience as we work to empower your asset management workflows with this feature.

Why did we change our Unreal Integration?

One of the most requested features of our Unreal integration was to have Wwise-related assets automatically created in the Unreal project hierarchy. It is really cumbersome to have to manually duplicate Event and SoundBank assets in Unreal. Keeping the Event names in Wwise in sync with the name of the associated Unreal asset requires manual renaming in Unreal. Also, Wwise SoundBanks have always required special consideration because they are not native Unreal assets.

How did we change our Unreal Integration?

To solve the issues described above, we introduced automatic Unreal asset creation based on the Events present in the Wwise project. As explained by Fan Runpeng in his Event-Based Packaging Process Overview, each Event in the Wwise project is automatically packaged in an Unreal asset. The existing Audiokinetic Bank asset type in Unreal can still be used to group Events, but the default behavior is to have a single Event per SoundBank stored in Unreal assets. Only the Event and Structure portions of an Event are stored in SoundBanks as the media for Events are handled separately. Storing SoundBanks in Unreal assets allows for the automatic update of Event names between Wwise and Unreal. 

What went wrong?

The Event-Based Packaging asset management workflow can be separated in three main components:

• Automatic single-event SoundBanks creation
• Asset Synchronization between Unreal and Wwise projects
• Automated asset lifetime handling (loading, unloading, preparing assets at runtime)

Each of these are far from trivial to implement and could be considered major features. As the changes affect the asset production pipeline in an Unreal project, they are risky features to implement.

While the automatic single-event SoundBanks creation did not cause problems, storing them in Unreal assets increased the amount of time needed to save them to disk. We didn’t catch this in our initial testing, but after hearing from teams working on larger projects shortly after release, we realized that this was slowing down their pipeline. This is not ideal and we plan to improve this but it is more an inconvenience than a problem.

It is the Asset Synchronization part of the workflow that has led to most problems reported by the affected teams. Bugs in the Asset Synchronization code also led to broken builds and version control issues that we were unaware of. Having our SoundBanks and media stored in Unreal assets also made the profiling of Wwise SoundBanks moot. (As SoundBanks are loaded in the engine’s memory, they are not visible from the Wwise profiler.) Additionally, the use of the efficient, but unsafe, SetMedia/UnsetMedia functions at the core of EBP was leading to many runtime crashes. 

The Unreal editor uses the Wwise Console tool to perform the SoundBank generation operation from the command line. Having Wwise generate these files to disk, and then reading and storing them in Unreal assets involves more disk I/O than previously. To improve the performance of this operation, sound data can be generated via WAAPI when the Wwise Authoring tool is connected. However, it also means we now have two ways of generating sound data to maintain. While this is not impossible, the complexity of the system has been hard to handle and support.

How do we plan to fix the problem?

We have been fixing bugs and issues as they’ve been reported since the introduction of EBP. The most crucial fix involved strengthening the SetMedia/UnsetMedia SDK functions to warn when it’s unsafe to free memory. We also moved from using soft-references to media in Wwise Event packaged .uassets to using hard-references, making the integration more reliable. There remain problematic usage scenarios that we cannot find a solution for in the current architecture, so we have started refactoring the features for Wwise 2022.1. 

Improving Wwise

To avoid having two ways to generate the sound data, we are adding a “single-event banks” option to Wwise’s SoundBank Manager to have the Wwise Authoring tool generate them. The new option, called “Auto SoundBank Generation”, will be available under the SoundBanks tab of the Project Settings. It will be disabled by default and will automatically generate SoundBanks for Events that are not currently in a SoundBank.

We have also improved the content of SoundBank metadata files to include all the information required by the runtime engine to playback the sound as intended by the designers. This allows us to forgo all asset synchronization code from our Unreal integration as it can rely on the metadata as the Single Source Of Truth (we call it SSOT). 

Simplifying the Unreal Integration

Instead of populating the Unreal Content folder automatically with all the items present in the Wwise project, Unreal assets will only be created when they are needed. Unless you choose to use a specific Event in your Unreal project, it will not create an asset on disk. These assets will only contain a reference to the resources it uses until you package your project. Only then will the SoundBanks be copied to the Unreal staging folder hierarchy. This will also solve the problem encountered by project members who do not work on audio, who sometimes had to install Wwise to have audio in their project. The new integration only requires the presence of the GeneratedSoundbanks folder to have full Wwise audio support in the project.

Migrating from EBP to SSOT

Migrating an EBP project to the new AutoBank/SSOT workflow will take some time, the length of the migration is directly related to the amount of Unreal assets under the Sound Data folder in the Unreal project. The migration will have to be performed on a system where Wwise is installed and the Wwise project should be open during the migration. We expect this will be a time-consuming task on a big project, thankfully it will only need to be done once.

What will change in the workflow?

The main goal we have given ourselves is to improve the experience of using the Wwise Unreal integration. Adapting to the new workflow will probably require a transition period but we think these changes will be worth it. The end result will be a more reliable Wwise - Unreal integration that is better adapted for teams collaborating using a version control tool.

Flexible GeneratedSoundBanks Location

A new metadata file (ProjectInfo.json) will be created by Wwise when the SoundBanks are generated, this file will contain the paths where the SoundBanks are generated for each platform. This will give teams greater flexibility in choosing where the SoundBanks are generated for each platform to suit their workflow. This should also address version control issues that are affecting many teams working with EBP.

Modifying Wwise Assets Names

The new workflow will not require a one-to-one match of an Event name in Wwise and its corresponding Unreal asset. Does this mean that it will not be possible to edit the Wwise Event names in Unreal? Absolutely not, we are enabling editing of names of items in the WAAPI picker, allowing you to rename elements of your Wwise project while Unreal is in focus. 

Unreal assets are like shortcuts to the content of the SoundBanks instead of being serialized data. They only contain IDs that allow the integration code to find what should be loaded in memory for Wwise to play sounds.

Minimal Support of External Sources

Another Wwise feature that was not handled by our Unreal integration before the introduction of EBP is the External Sources feature. Because many studios have developed their own integration of this Wwise feature in Unreal, they did not switch from their solution to use the one offered by the integration code. Some even had to remove the External Sources support from the integration code as it interfered with their solution. 

We are making the External Sources feature from the Unreal integration completely optional.

The Bottom Line

The last two years have been quite a journey for the Wwise Unreal developers who adopted the EBP workflow. Many teams told us they love it and would not want to go back to the manual SoundBank management workflow. Other teams want to use it but its limitations had too much impact on their workflow. We have considered all the feedback, the good and the bad, to refactor the integration code during the past year.

Bringing the EBP feature to Wwise Authoring and using the SSOT strategy in the integration code is the right direction in our view. Moving away from using Unreal assets gives audio teams clarity in their pipeline. Other teams using their own engine will be able to implement the AutoBank and SSOT workflow. It also creates a clear path for improving our Unity integration in future releases.

If you are interested in trying the new workflow for the Wwise Unreal integration, keep an eye out for the Wwise 2022.1 beta release coming this Spring.