Wwise SDK 2019.1.11
|
The first step in integrating the Wwise sound engine is to properly initialize the various modules that make up the sound engine when the game starts up.
In this sample project, the following function is defined to perform everything related to initialization of the sound engine:
It is called at the beginning of the main function. Let's look at the various items that need initializing:
Every project that links with the Wwise sound engine must define several hooks. These can then be used to monitor calls to memory access methods.
The first thing you must initialize is the Memory Manager. The following code creates the default Memory Manager with twenty memory pools:
Note: You can override the Memory Manager, in which case the code presented above must be adapted as needed. Refer to Overriding the memory manager for more information. |
Refer to Memory Manager for more details regarding the Memory Manager.
Once the Memory Manager has been initialized, we can move on to the Streaming Manager.
The following code initializes the default Streaming Manager. It requires an instance of AK::StreamMgr::IAkFileLocationResolver, and creates a streaming device. This requires an instance of AK::StreamMgr::IAkIOHookBlocking or AK::StreamMgr::IAkIOHookDeferred, depending on the streaming device scheduler type (AK_DEVICE_BLOCKING or AK_DEVICE_DEFERRED_LINED_UP). These interfaces are defined in AkStreamMgrModule.h, which contains all definitions that are specific to the default Stream Manager implementation provided with the SDK.
The recommended way of integrating the sound engine with regards to disk I/O is to use the default Stream Manager implementation, and implement the interfaces defined in AkStreamMgrModule.h. These interfaces constitute the Low-Level I/O submodule. Refer to Streaming / Stream Manager for more information.
This example uses the sample CAkFilePackageLowLevelIOBlocking as is. This class implements both AK::StreamMgr::IAkFileLocationResolver and AK::StreamMgr::IAkIOHookBlocking interfaces, and is able to load file packages generated with the File Packager utility (refer to File Package Low-Level I/O Implementation and File Packager Utility for more information about the File Packager and how it works in the Low-Level I/O).
Refer to Low-Level I/O for more information about the Low-Level I/O.
For more information about the initialization settings of the default Stream Manager and streaming devices, refer to Audiokinetic Stream Manager Initialization Settings.
Caution: Some of the initialization settings use member structures that are platform specific, like the AkThreadProperties. |
If you decide to override the default Low-Level IO implementation, or the complete Streaming Manager, this code will need to be adapted accordingly. Refer to Streaming / Stream Manager for more information.
Now that the basic modules have been initialized, we're ready to initialize the sound engine itself:
For more information about how to initialize the sound engine, refer to Advanced Sound Engine Integration
If your project uses the Interactive Music feature, the music engine must be initialized after the sound engine.
If you want to be able to use the Wwise authoring application to connect to your game and perform in-game mixing, profiling and troubleshooting, the next step is to initialize communications. It is strongly recommended to do so, as in-game mixing, profiling and troubleshooting are extremely powerful ways for the sound designer to work on your game's audio in a more efficient way.
Note: To use communications, you need to link with the CommunicationCentral module. |
Note: Communications are available in the Debug and Profile configurations of the sound engine only. They are not needed in the retail version of your game, so they are not part of the Release build of the sound engine. The following code uses the AK_OPTIMIZED symbol to leave communication-specific code out of the release build. |
You have now initialized all of the sound engine's modules. You should then register the plug-ins (see Plug-in Example). Refer to Create Recurring Calls to Perform Audio Processing for details on the calls you must make in your game loop to process the audio.
Some console communication libraries don't balance the initialization/termination calls properly; therefore, calling AK::Comm::Term will terminate the underlying low-level communication library for the console. This effectively closes all TCP/IP communication for the game. If your game needs to keep the communication libraries enabled after termination, AkCommSettings (used with Ak::Comm:Init) has a parameter to initialize the system library or not. If you choose to initialize the communication library yourself, check the code used by the Wwise sound engine below. The game should do something similar.
Windows sockets initialization:
Termination:
The AkCommSettings::ports member of the AkCommSettings structure represents network ports used for communication between the Wwise authoring application and the sound engine. All of these ports are opened in the game when Wwise communication is enabled.
One of the ports, AkCommSettings::Ports::uDiscoveryBroadcast, cannot be dynamic (cannot be set to 0). The authoring application needs to be aware of it in order to discover games on the network. Furthermore, the value specified here must be the same value specified in the Network tab of the Project Settings within the authoring application.
Tip: If your team is working on multiple games using Wwise, you might want to use different Discovery Broadcast ports for each game. That way when you open the Remote Connections window in the Wwise authoring application, only games corresponding to the currently opened Wwise project will be listed. When changing this port, be sure to change it both in the Project Settings within the authoring application and in the AkCommSettings structure you pass to AK::Comm::Init() in the game. |
The two other ports in the structure can be dynamic (or "ephemeral"). This means that instead of using a fixed port, one is automatically picked by the operating system:
These ports are dynamic by default. It is recommended to keep them dynamic in order to minimize chances of conflicts with other applications.
Wwise requires three sequential channels to works properly, and they must be ordered in the order they are presented in the Port structure. In Wwise, you can select the base port (By default 8).
If they conflict with ports used by other components of your game, simply change them in the AkCommSettings structure before calling AK::Comm::Init().
Note: In a multi-platform game, it is valid to use different ports on different platforms for AkCommSettings::Ports::uCommand and AkCommSettings::Ports::uNotification. |
Tip: For more information on dynamic/ephemeral ports, consult these articles: |
There is one more port involved in Wwise communications, but since it is opened in the authoring application only, it is not part of the AkCommSettings::Ports structure.
That port is used by the authoring application to receive reponses to the Discovery Broadcast messages sent to detect games running on the network. It is dynamic by default (set to 0) but can be changed in the Project Settings within the authoring application.
Questions? Problems? Need more info? Contact us, and we can help!
Visit our Support pageRegister your project and we'll help you get started with no strings attached!
Get started with Wwise