Table of Contents
This chapter contains information that is specific to using the Wwise SDK for the iOS/tvOS platform.
||Warning: tvOS SoundBanks must use iOS for their base platform.|
||Note: Unless otherwise specified, the mention "iOS" in this page and its subsections is used to describe interchangeably the iOS and the tvOS specific platform details.|
It is common to have stuttering or voice starvation on Android and iOS when using Bluetooth®. Because Bluetooth is made for streaming low-bandwidth data (compressed voice band-limited at 8 kHz), not interactive audio, there is not much that can be done.
However, while recognizing that some hardware models are more affected than others, adding more latency buffers can often help avoid the glitches. To so, change the
AkPlatformInitSettings.uNumRefillVoices to 5 or 6.
On iOS, many events such as an incoming phone or FaceTime call, usage of SIRI, calendar alerts, or system sounds can prevent app audio from playing at any moment. In order for the app audio to be restored, it is the app's responsibility to properly manage the audio interruptions. Similarly, app switching must also be handled properly for app audio to be paused/resumed as expected. Failure to implement these required steps will result in inconsistent audio behavior, app silence, or a crash. Apple's audio session is the mechanic that handles access to audio hardware on the device and acts as the conductor for audio access and sharing among apps and the rest of the system. Every app that deals with audio on iOS must know how to work with audio session. Fortunately, most of the implementation details when working with audio session are taken care of by the Wwise iOS SDK and little effort is required by the SDK client app to obtain a compliant and efficient audio app that behaves as expected. The following sections present the concept of the iOS audio session and its related Wwise-implemented policies.