top of page

Wwise Implementation


This section is made to be a journey log for implementing Audiokinect's audio middleware Wwise into a custom game engine. This implementation is to be used for the last project at The Game Assembly and is to be used by two student groups, making two different games using the same game engine. 

Project Specifics:

Time frame: 8 weeks at 100 %

Engine: Custom Engine

Rules: Needs to work for two projects worked on by two different studios.


Wwise Documentation

Game Audio Programming by Guy Somberg

Molly Tandberg (TGA Student)

Week 1

Implementation Goal:

Set up a base Wwise implementation that can play a sound by accessing a audio manager interface.

The first week of implementation was to simply get Wwise integration up and running and to simply play a 2D sound. 



Wwise Engine SDK Sample Sound Engine:

A basic Wwise integration has one weird

section to it and that is the initialization of

the the stream manager and its low level IO

implementation. For some reason this is not part of the includes/library packages, but Wwise wants you to go into the SDK sample project and collect certain .h and .cpp files from that project. A solvable problem but a inconvenient one.



This is part of Wwise's memory handling that would throw constant asserts for me. What is does is allocating memory onto the heap and return a pointer to the start of the allocated memory, but will return NULL if the allocation could not be completed. The root of this problem was that I've defined the class of my wrapper implementation as a static and somewhere in the black box of the Wwise engine it tries to allocate memory but could not succeed because of this static class.  This problem was solved by changing the class implementation to a singleton. Why this solves the problem I am not entirely sure and are currently searching for an answer. My theory is that is has to do with differences in static- and dynamic memory allocation, and when and how they are allocated.


Week 2

bottom of page