Androidでのレイテンシーのコントロール

Androidオーディオのレイテンシーは、すべてのアプリケーションで常に問題となっていました。通常のレイテンシーは100ミリ秒以下ですが、一部のデバイスでは最大150 msのレイテンシーを示します。

最近のOSバージョンでは、Googleは "高速オーディオパス" を導入しました。これにより、いくつかの条件が満たされた場合に内部処理の一部がバイパスされ、OSおよびハードウェア処理の待ち時間が大幅に短縮されます。全体的なレイテンシーは、数十ミリ秒に短縮することができます。ハードウェアメーカーが高速オーディオパスを実装することは必須ではないことに注意することが重要です。そのため、多くは実装されていません。さらに、一部のデバイスでは、実際に実装されていない高速パスを通知します。 したがって、ゲームは、エンドユーザのデバイス上の高速オーディオパスの存在を信頼することはできません。 ゲームが幅広いターゲット市場を対象としている場合は、この機能を使用せずにゲームオーディオを設計する必要があります。

一般に、レイテンシーが短くなるとCPU負荷が高くなります。RTPC更新、ゲームオブジェクトの位置、他のゲーム入力などの処理は、フレームごとに行われます。したがって、より小さなフレームでは、これはより頻繁に処理されます。レイテンシーとCPU使用率とのバランスは、実験を通じてのみ見つけることができます。厳しいルールはありません。

レイテンシーをコントロールするWwiseの初期設定

いくつかの設定は、Wwise SDKのオーディオレイテンシーを制御します：

• AkPlatformInitSettings::uSampleRate： 使用するサンプルレートハードウェア推奨レート（およびフレームごとのサンプル）に設定すると、オーディオ高速パスを選択できます。
• AkPlatformInitSettings::uNumRefillsInVoice: 前処理するバッファの数。これは、CPU使用状況と中断からの保護です。
• AkInitSettings::uNumSamplesPerFrame: バッファあたりのサンプル数。ハードウェアの推奨サイズ（およびサンプルレート）に設定すると、オーディオの高速パスを選択できます。

デフォルト設定、ワンサイズ対応レイテンシー

AK::SoundEngine::GetDefaultSettings() and AK::SoundEngine::GetDefaultPlatformInitSettings() によって返されるデフォルトの設定は、ほとんどのデバイスで、ほとんどの場合" 安全" な設定です。それらを使用して設定します：

• uSampleRate をハードウェア推奨レートに設定します。これは通常48 kHzまたは44.1 kHzです。
• uNumSamplesPerFrame を 1024 に設定します。
• uNumRefillsInVoice を 4.に設定します。

メリット： この設定は、ほとんどのデバイスでのスタベーションに対する優れた防御を提供します。また、オーディオ設計のCPU使用率に関する制約も少なくなります。
デメリット：レイテンシー（約86ms）、シンク（0~21ms）、ハードウェア処理（それによる）の1024 * 4 サンプルがあります。

最短レイテンシーの設定

最短レイテンシーでWwiseを初期化するには、 AK::SoundEngine::GetDefaultSettings() と AK::SoundEngine::GetDefaultPlatformSettings()を呼び出し、そして AK::SoundEngine::GetFastPathSettings() を呼び出します。これにより、デバイスの環境設定でデフォルト設定が上書きされます。.

これで設定します：

• uSampleRate をハードウェア推奨レートに設定します。これは通常48 kHzまたは44.1 kHzです。
• uNumSamplesPerFrame をハードウェア推奨レートに設定します。これは、デバイスに応じて96〜512サンプルの間です。通常、128または240サンプルのオーダー。
• 手動で\ uNumRefillsInVoiceを2に変更します。

メリット：レイテンシーはデバイスに依存しますが、一般的な範囲は240 * 2 サンプル (10 ms) とハードウェア (未知)です。
デメリット： 使用可能なCPUは限られます。オーディオのレンダリングに割り当てられる時間は非常に短く、システム上の他のイベントによって簡単に妨げられる可能性があります。オーディオ設計（RTPC、Switch、 Positioning、コンテナなど）のCPUオーバーヘッド（負荷）は懸念事項で、注意深くモニタリングする必要があります。

最小レイテンシーと最大レイテンシーの中間点

上記の2つの設定の間には、ターゲットデバイスとオーディオ設計に応じてそれぞれのゲーム開発者が見つけなければならない妥協点があります。 uNumSamplesPerFrame を整数倍で変更し、使える場合は高速オーディオパスを使用できます。CPUのオーバーヘッドを制御する方法もあります。：uNumSamplesPerFrameを２倍にすると、Wwiseのビヘイビアのオーバーヘッド（負荷）が半分で計算されます。

uNumRefillsInVoice は、CPU使用率の変動にいくらかの余裕を持たせるために、少なくとも3、ほとんどのゲームでは通常4に設定する必要があります。

メリット： CPU使用率はハードウェアによって制約されません。オーディオのレンダリング時間は大きく異なり、より複雑でダイナミックな設計が可能です。
デメリット： CPUの使用可能度は保証されません。したがって、オーディオ設計やその他のアプリケーション（ゲームの残りの部分やデバイス上の他のアプリケーションなど）によっては、より高いバッファリング（レイテンシー）が必要な場合があります。

Bluetooth の例外

Androidのプログラマーのメモにあるように、Bluetoothデバイスはレイテンシーを短くすることが出来ず、高速パスを使用します。実際に、Bluetoothデバイスで問題のないオーディオを使用するには、バッファリングが非常に高く、フレームが大きくなければなりません。WwiseはBluetoothヘッドセットの使用状況を検出し、オーディオハードウェアを自動的にリセットして8,192サンプルのレイテンシーを約180msにします。