版本
Wwise SDK 2018.1.11
|
iOS SDK 依靠 Apple 音频会话 API 来遵守应用内和应用间的操作系统音频处理机制。音频会话的主要目标是,当不同系统事件或用户操作发生时,为音频应用程序提供规范行为。换言之,音频会话是音频应用程序与 iOS 操作系统之间的中间层,提供了可预测的音频行为。
应用程序针对系统和其他应用程序的音频行为通过一系列音频会话类别和子类别(被称为类别选项)来控制。使用音频或用于制作音频的每款 iOS 应用程序都应自行注册到系统中的特定音频会话类别和类别选项集合(可选),以表明它的预期音频行为。
音频会话还用于处理和响应 iOS 系统中断和音频通道变换。
最后,音频会话还是 iOS 底层硬件音频组件在不同音频应用程序和系统声音之间的共享机制。因此必须满足音频会话需求,防止系统事件处理不当导致应用程序崩溃或音频丢失。
每当音频应用程序需要捕获或者产生音频时,它必须请求并在系统上激活音频会话。例如,当音乐应用程序用户按“播放”按钮时,应用程序应在按钮被按下后请求激活它的音频会话,并在用户按下“暂停”按钮时停用该功能。许多 iOS 内置应用程序使用音频会话来输出或采集音频,这可能会对用户应用程序音频行为产生影响:
iOS 可以随时停用应用程序的音频会话来响应各种其他音频事件,例如手机来电、定时器设定的音频报警或者日历事件。这些事件被称为 interruption(中断)
, 音频应用程序可以对此类音频会话优先级变更作出反应,并在中断结束后正确恢复播放或录音。应用程序切换、按下主页按钮后在后台运行应用程序以及锁定和解锁设备时,也会激活和停用音频会话。以下各节详细介绍 Wwise 如何管理这些事件,以及客户端应用程序须采取何种措施来确保音频正确播放。
iOS 上运行的所有音频应用程序都必须使用音频会话来处理、获取或输出声音。由于所有音频应用程序使用音频不一定为了同一目标或目的(音频录制应用程序可能需要获取音频在后台执行,而游戏会在另一音频程序启动时完全暂停),iOS 定义了几种音频会话类别,对用户操作或系统事件发生时的预期音频行为进行分组。每款音频应用程序必须自行注册使用给定类别,然后才能在设备上处理音频。
各类的不同音频行为主要包括:
每款音频应用程序仅隶属于一种类别。如果没有具体选定具体类别,则会使用默认的AVAudioSessionCategorySoloAmbient
类别。iOS Wwise SDK 中提供三个主要类别:
AkAudioSessionCategoryAmbient
:相当于 iOS 音频会话 AVAudioSessionCategoryAmbient
类别AkAudioSessionCategoryOptionMixWithOthers
选项(见下文)来进行播放和录制,那么在后台激活其音频会话时,该程序音频将与现有应用程序音频混音。Ambient
类别中的所有应用程序音频将与其他应用程序的音频混音。最常见的情形是用户启动 Music 应用程序并开始播放音乐,然后切回到您的应用程序。Ambient
不支持从您的应用程序在后台播放音频。如果用户从您的应用程序切换到另一音频应用程序,即使其他应用程序使用 mixable(可混音)类别,您的应用程序音频也将静音。AkAudioSessionCategorySoloAmbient
:相当于 iOS 音频会话 AVAudioSessionCategorySoloAmbient 类别Ambient
类别的主要区别在于,当其音频会话激活时,其他应用程序的音频会中断。AkAudioSessionCategoryPlayAndRecord
:相当于 iOS 音频会话 AVAudioSessionCategoryPlayAndRecord 类别AkAudioSessionCategoryOptionMixWithOthers
选项(见下文),并且其它应用程序的音频(例如来自 Music 应用程序或另一音频流播放应用程序(如 Spotify)的音乐)在播放时将不与您的应用程序音频混音。AkAudioSessionCategoryOptionMixWithOthers
(见下文),则当另一音频应用程序在后台激活其音频会话时,应用程序音频将不与其他源混音。例如,使用 Music 应用程序听音乐的用户切回到您的应用程序时,它们的音乐将与您的应用程序音频混合。然而与 AkAudioSessionCategoryAmbient
一样,使用此选项仍然不会输出来自在 Wwise 中设为静音的应用程序 BGM(请参见 处理用户音乐(BGM)和DVR 了解详情)。音频会话类别选项可以配有 enum AkAudioSessionCategoryOptions
:
AkAudioSessionCategoryOptionMixWithOthers
:相当于 iOS 音频会话 AVAudioSessionCategoryOptionMixWithOthers
类别选项AkAudioSessionCategoryPlayAndRecord
类别使用。AkAudioSessionCategoryOptionDuckOthers
:相当于 iOS 音频会话 AVAudioSessionCategoryOptionDuckOthers
类别选项AkAudioSessionCategoryPlayAndRecord
类别使用。AkAudioSessionCategoryOptionAllowBluetooth
:相当于 iOS 音频会话 AVAudioSessionCategoryOptionAllowBluetooth
类别选项AkAudioSessionCategoryPlayAndRecord
类别使用。AkAudioSessionCategoryOptionDefaultToSpeaker
: 相当于 iOS 音频会话 AVAudioSessionCategoryOptionDefaultToSpeaker
类别选项AkAudioSessionCategoryPlayAndRecord
类别使用。在 iOS 设备上,当您的应用程序正在使用其音频设备时,可能发生一定数量的用户操作或系统事件。例如,呼入电话、用户从您的应用程序切换到另一个应用程序、定时器声音提醒响起、用户将耳机插入/拔出插孔或者用户按下 Ring/Silent 开关,都是对您应用程序的音频行为可能产生影响的事件。本节介绍 iOS 中应对此类事件的不同机制,以及如何通过 Wwise 与您的应用程序通信。
iOS 中存在三种主要音频事件:中断、源变换和通路变换。
- 中断
不同的系统事件或用户操作可能导致应用程序音频会话功能的停用,也被称作音频会话中断。例如在收到呼入电话,或者另一不可混音的音频应用程序的音频会话激活时,就会发生此类中断。在应用程序被操作系统转至后台时,声音引擎的行为取决于 Audio Session 类别。
在 Solo Ambient 类别中,音频无法进行混音。因此,声音引擎将暂停工作。这时,既不会处理音频,也不会调用 API。这样可以节约 Apple 设备电量。游戏也会暂停处理,避免调用 AK::SoundEngine。在应用程序返回前台后,声音引擎将恢复工作,并处理队列中的 API 调用。系统将自动执行所有这些操作。
在 Ambient 或 Play and Record 类别中,或者在可通过其他应用程序对音频进行混音的其他模式下,声音引擎通常会继续处理音频。
若应用程序需要知晓这些系统事件,而游戏引擎并未予以告知,则可在 AkPlatformInitSettings.audioCallbacks.interruptionCallback 中设置回调函数。否则,声音引擎将无从处理这些事件。
发生音频会话中断时,被中断的应用程序可以由一条消息获得通知,该消息将转换成 Wwise SDK 中的应用程序回调。音频会话中断分为两个事件:中断开始时的通知和中断结束时的通知。在 Wwise SDK 回调中,中断的开始/结束都可通过回调参数获取。
当收到这些中断时,Wwise 负责暂停/恢复声音引擎组件,用户无需采取进一步的行动来确保正确地激活/停用音频会话。当音频会话中断或恢复时(例如更新 UI 元素或提供有关中断的视觉反馈),如果 SDK 客户应用程序中需要进行特别处理,必须把代码添加到上述的应用程序回调中。当 Wwise SDK 中收到“开始”中断时,在声音引擎中断前将调用用户回调。另一方面,当 Wwise SDK 中收到“结束”中断时,声音引擎在调用用户回调方法之前恢复。
Caution: 由于“开始”音频中断回调在内部暂停声音引擎之前调用,因此它不能用于播放任何类型的音频,甚至短暂声音,因为无法保证达到预期的结果。 |
Caution: 用户音频中断调用只用于执行简单的任务,例如 UI 或对象属性更新,而决不可用于执行 CPU 密集型计算或者耗时的操作。否则下无法保证达到预期的结果。 |
Caution: Apple iOS 文档中警告,“开始”中断通知不一定总与中断结束通知相匹配,并且唯一能够检测何时恢复音频会话的方式是靠应用程序切回到前台时调用委托方法。因此音频应用程序中,音频中断回调不应是检测音频会话恢复的唯一机制。 |
- 源变换
当音频应用程序开始播放音频时,iOS 可以使用活动的音频会话来通知目前正在前台运行的其他应用程序有关此新会话激活的信息。如果您的应用程序是环境、播放并录制以外的其他会话类别,而且激活了可混音选项,将会导致音频会话被 iOS 停用。因此,该通知只有在使用 可混音类别时才真正有用。主要目的是让应用程序决定是否应在另一应用程序播放音频时,将其部分或所有音频设为静音/取消静音。此 iOS 通知会进一步转换成 Wwise SDK 回调,它可以像上述的音频中断一样注册到您的应用程序中。源变换回调还带有“开始”或“结束”事件,从而让应用程序知道另一音频应用程序是否激活或停用了其音频会话。
struct
AkInitSettings
中的成员 sourceChangeCallback
是为上述音频源变换回调保存用户回调的函数指针。Integration Demo 为此使用了静态的 AKRESULT DemoInterruptCallback(bool in_bEnterInterruption, void* in_pCookie )
方法。选定的方法将注册为源变换回调,方法是将函数地址设置为回调方法地址: initSettings.sourceChangeCallback
= DemoAudioSourceChangeCallback
。bool
in_bEnterInterruption
参数反映激活/停用另一应用程序音频会话的“开始”或“结束”通知状态。用户定义的可选回调 cookie 还可以设置为 struct "AkInitSettings BGMCallbackCookie"
成员。
一旦注册,Wwise SDK 中音频源的每个源变换通知或者显式验证都将触发回调。
如果您的应用程序使用可混音类别(不沿用可混音选项的环境或播放并录制类别),Wwise 在收到“开始”或“结束”源变换通知时,将分别在内部设置后台音乐总线为静音或者取消静音。当收到“开始”源变换通知时,内部后台音乐总线将在调用用户回调方法之前静音。同样,当收到“结束”源变换通知时,后台音乐总线将在调用用户回调之前取消静音。
在非可混音类别下(在不沿用可混音选项的情况下独奏环境,或播放并录制),当另一应用程序在后台激活其音频会话时,iOS 发送的是音频中断“开始”而非源变换通知,因此用户不应期待在此类情况下的源变换回调使用“开始”参数。但如果还注册了音频中断回调,用户接收此回调时将收到“开始”参数而非源变换回调。
Note: 如上所述,由于音频中断“开始”回调后声音引擎将内部暂停,因此在另一应用程序停用其音频会话时,收到的匹配源变换“结束”回调将负责内部恢复声音引擎,无需用户采取进一步行动。 |
- 通路变换
音频通路是音频通过设备中不同音频硬件组件的指定路径。例如当用户插入或拔出耳机时,音频通路将变换,因为声音输出应发送到耳机或被暂停而不是通过设备扬声器传出。iOS 可以将通路变换情况通知给注册了 AVAudioSessionRouteChangeNotification
的应用程序。
发生基本的通路变换(例如插入/拔出耳机)时,Apple 音频会话自动负责激活/停用正在运行的应用程序的音频会话。Wwise SDK 不提供违背上述中断和音频源变换案例的回调机制。如果用户需要检测此类通路变换来让应用程序中的特定元素做出反应,请参阅“Integration Demo”来了解如何轻松实现。