Wwise SDK 2022.1.9
With many new features, you will need to pay attention to several things when migrating to Wwise 2017.2.
In the SDK lib files:
In the SDK bin files:
In the Authoring\x64\Release bin:
The management of outputs (Main, BGM, Game Controller Speakers, Headphones, DVR, and so on) was overhauled for 2017.2. Now, all audio sinks (the part that talks to audio hardware) use the plug-in model, including the ones provided by Audiokinetic with Wwise. Therefore, all projects now have Audio Devices ShareSets of each type added to their project, if they use at least one of the supported platforms. Each Master Bus (a bus that sits at the top of the mixing hierarchy) must now have an Audio Device attached to it to define into which output the mix will go. This function was previously done by code either during initialization (through
AkInitSettings) or with
AK::SoundEngine::AddSecondaryOutput. During the migration to 2017.2, existing projects will have the System device automatically added to the Master Audio Bus and to the Master Secondary Bus.
|Caution: Review your usage of the Master Secondary Bus! If you used it before, you must select the proper Audio Device. You might have to split your bus hierarchy to have a separate Master Bus for another output. You can now create as many Master Busses as you need, normally one per hardware output.|
|Caution: If you used plug-ins for your main output (PSVR binaural plug-in for example), make sure to link them to the Master Audio Bus' Audio Device property. If this plug-in is supported only on one platform (PS4, for example), make sure to use the Link/Unlink functionality to set the property correctly on all platforms.|
Additionally, Listener management with respect to Secondary Output has been changed. In general, the old code should behave the same way unchanged. However, it is worth mentioning that the system requires fewer Listeners if only one device of a given type can exist. Please read Integrating Secondary Outputs for more information.
AK::SoundEngine::AddSecondaryOutputwas changed to
AK::SoundEngine::AddOutput, with different parameters. Same with
RemoveSecondaryOutput. Refer to the functions' documentation. You will need to locate the proper Audio Device name (or add one) in your Wwise project to have the same functionality with
AkInitSettings) and in
AK::SoundEngine::AddSecondaryOutputis removed. Its functionality is replaced by the plug-in mechanism for Audio Devices.
AK::SoundEngine::SetSpeakerAnglesall take an
AkOutputDeviceIDis returned by
AK::SoundEngine::AddOutputor the new function
The whole motion (rumble) system was refactored to use the generic Audio Device plug-in mechanism and the new output system, instead of the old separate code path. Motion devices are now considered as Audio Devices instead of having a special status. This streamlines the code and data model for Motion objects and allows the use of all the same feature set as the audio pipeline. Therefore many changes to existing code are necessary to get the same Motion effects. Most changes to the Wwise project are done automatically and transparently. See the section Basic project migration changes: below to learn about the changes made to your project.
AK::MotionEngine namespace was removed. Therefore, to replace
AK::MotionEngine::AddPlayerMotionDevice, you must now call AK::SoundEngine::AddOutput, with the proper Audio Device ShareSet name (usually Wwise_Motion). This Audio Device should have been added automatically to your project.
Also, the Listener management related to Motion has changed. Instead of calling
AK::MotionEngine::SetListenerPipeline, you need to provide the listener linked to the player as a parameter to
AK::SoundEngine::AddOutput. Note that this listener is optional now, if you only have one player in the game. Multiplayer games will still need to manage listeners properly.
Existing projects will be migrated to the new system automatically. Here's the list of changes to look for in your project:
|Note: If motion was not used in a project (there is no reference to a Motion Bus), all Motion Busses in the project will be deleted. Additionally, the Wwise Motion ShareSet will not be added, even for projects that support it.|
A few scenarios arise because we are now using a basic user aux bus send rather than a separate Motion Bus path:
|Note: For the subsections below: In the process of copying a user aux send we copy the bus reference, the volume, and the LPF. Any RTPC, Modulator LFO, Modulator Envelope, and Curve or Modifier on the volume or LPF is copied as well. Any IDs (unique ID and ShortID) are regenerated to mitigate ID clashes when loading the migrated project. For any clashes that remain (more likely with the ShortID) the Wwise project load procedure will resolve them (with a warning in the Project Load Log).|
|Warning: Any copying of user aux sends from a node to a descendant has the (initial) equivalent effect of setting the descendant to inherit the node's aux send, but if any change is made to the node's aux send it will not be reflected in the descendant.|
The following functions have been renamed to better reflect their intended usage:
The previous names were deprecated and should not be used in new code.
Clientclass will not compile if you provided a timeout in the constructor. The timeout is no longer the same for all method calls to the client, it must be provided at each call.
The 32-bit Wwise Authoring was removed. Now both Windows and macOS Wwise Authoring are only compiled with 64-bit support.
Please note that 32-bit support is still available for the Wwise SDK libraries.
While revamping the built-in LPF/HPF pipeline, we removed the arbitrary condition restricting obstruction/occlusion to game-defined positioning. If you relied on the fact that sounds with 3D user-defined positioning were always unobstructed/unoccluded, you will have to use a different game object for those sounds.
In Wwise 2017.2, Auxiliary Busses will now process the dry signal; it will not be ignored. A migration was put in place to mute the dry signal of affected Effects that are placed on aux busses. The Effects affected by this change are:
|Caution: If an Effect is applied to an aux bus and another type of medium, it will also be muted, which may change the behavior of your project.|
Users must delete the Spread curve of the Attenuation ShareSet used on aux busses (portals) in order to benefit from Spatial Audio's geometry-driven spread calculation.
AK::SpatialAudio::SetEmitterAuxSendValue should no longer be called for sending to Rooms' aux sends, as this is now specified in
AkRoomParams and managed entirely by Spatial Audio.
AK::SpatialAudio::SetEmitterAuxSendValue adds its sends to those of Rooms and can thus be used for customizing or implementing more complex reverberation regions within the same room.