2024.1.4.8780
2023.1.12.8706
2022.1.18.8567
2021.1.14.8108
2019.2.15.7667
2019.1.11.7296
2018.1.11.6987
2017.2.10.6745
2017.1.9.6501
2016.2.6.6153
2015.1.9.5624
|
Wwise SDK 2018.1.11
|
Almost all operating systems have callbacks or notifications for the following events:
These events are not handled automatically by Wwise. The main reason is that some of the OS APIs don't allow multiple callbacks or notification receivers. Therefore, the Wwise SDK needs to be told of those events to avoid "eating" those events instead of the game.
For information on how to handle user-music replacements, please read Handling User Music (BGM) and DVR.
In general, all game systems can put the application in the background for a time. Wwise can have three possible behaviors, depending on your preferences or the platform's requirements:
In general, when the application is put in the background and Suspend(false) is used, the game should not call any of the sound engine APIs. Posting events and such would work, but would accumulate and be played all at the same time when the system would be awoken. To resume the audio processing, call AK::SoundEngine::WakeupFromSuspend() followed by a call to RenderAudio() when receiving the proper notification from the system. You may queue up other events before calling RenderAudio().
You should read about each platform's requirements in the manufacturer's documentation to choose the right behavior.
On Android, it is important to handle the App Lost/Gain Focus and the App Pause/Resume events. Google's requirements state that an app that is not in the foreground should use as little CPU as possible (preferably none). This can be achieved by calling Suspend(false) . See also BGM details for Android.
Apple requires that as little CPU as possible is used when the application is in the background. This is handled automatically by Wwise. See also BGM details for iOS.
There are no official guidelines for Mac, but it would be coherent with other platforms to cut the sound with Suspend() when the application process is not active. Whether this is a hard suspend (false parameter) or an active suspend (true parameter) depends on the game implementation.
There are no official guidelines for Linux, but it would be coherent with other platforms to cut the sound with Suspend() when the application process is not active. Whether this is a hard suspend (false parameter) or an active suspend (true parameter) depends on the game implementation.
While there are no explicit requirements for Windows, muting the audio while the application is not in the foreground is usually desirable. To do so, you should provide the hWnd of your main window to the AkPlatformInitSettings structure when calling Ak::SoundEngine::Init(). The audio thread will keep running in this case (equivalent to Suspend(true) ). This is handled by the OS.
Alternatively, you could also handle the WM_SHOWWINDOW message and do something more specific when minimizing, like fading out the audio or calling Suspend() directly.
Des questions ? Des problèmes ? Besoin de plus d'informations ? Contactez-nous, nous pouvons vous aider !
Visitez notre page d'AideEnregistrez votre projet et nous vous aiderons à démarrer sans aucune obligation !
Partir du bon pied avec Wwise