はじめに
Scalable Hardware Audio Processing Engine (SHAPE) は、オーディオ再生および操作の一般的な構成要素の多くにハードウェア アクセラレーションを提供します。 タイトルは、Audio Control Processor (ACP) が管理する SHAPE 処理ブロックの構成と順序を完全に制御できます。ACP はハードウェア コンポーネントです。タイトルは、入力から出力まで 1 つ以上の SHAPE コンポーネントを連鎖させるための定義済みパスを作成します。これらのパスはフローグラフと呼ばれます。作成されたフローグラフは、ACP が処理するための一連のコマンドとして送信されます。 このトピックでは、実行時に最も頻繁に遭遇するシナリオを正しく実装するためのフローグラフの作成および送信のベスト プラクティスと、パフォーマンスを最大化するために避けるべき構成について説明します。 このトピックでは、次の内容について説明します。SHAPE コンポーネントと機能
フローグラフがハードウェアに送信されると、ACP によりコマンド キューが自動的に管理および設定されます。 以下の表に、コンポーネントとそのインスタンス化機能の統合リストを示します。
以下の表に、コンポーネントとそのミックス バッファー ルーティング ルールの統合リストを示します。
| SHAPE コンポーネント | インスタンスあたりの入力ミックス バッファー | インスタンスあたりの出力ミックス バッファー |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| XMA| 該当なし。メモリから読み取ります。| 該当なし。メモリにデコードし、通常は SRC で消費されます。|
| SRC| 0。メモリから読み取ります。| モノラルの場合 1、ステレオの場合 2。|
| FLT/VOL| 1。| 1。|
| EQ/CMP| 1 (サイドチェーン構成の場合は 2)。| 1。|
| MB| 該当なし。ミックス バッファーは他のミックス バッファーから直接読み取ることはできません。| 該当なし。ミックス バッファーは他のミックス バッファーに直接書き込むことはできません。|
| DMA| 1。1 転送あたり最大 32 オーディオ フレーム。| 1。1 転送あたり最大 32 オーディオ フレーム。|
SHAPE の構成要素の詳細については、関連する Xfest トーク The Sound of XBOX One (Conference Material > Xfest 2012) およびホワイトペーパー The Sound of the Future (Developer Education Materials > All NDA Whitepapers) を参照してください。
フローグラフの使用シナリオに関する注意
多くのタイトルは、フローグラフを直接実装しないことがあります。XAudio2 は SHAPE コンポーネントを暗黙的に実装しており、オーディオ ミドルウェアは、ハードウェア フローグラフをタイトル開発者から抽象化することがあります。ただし、フローグラフを構築することで、XBOX One コンソールのオーディオ アクセラレーション機能を直接活用できます。具体的には、独自のオーディオ レンダリング ソリューションを開発および実装する場合や、XAudio2 やミドルウェアがサポートしていないカスタム構成がある場合です。 開発するすべてのタイトルにおいて、このトピックの後半で説明する SHAPE の機能を理解し、潜在的なフローグラフ トポロジを事前に計画することは価値があります。パフォーマンスが劣化するシナリオと病的なケース
以下のセクションでは、パフォーマンスの問題を引き起こす可能性のある一般的なシナリオについて説明します。また、これらの問題を回避するための推奨事項も提供します。不正なフローグラフ
不可能な信号フローや、出力で決して実現されないデータを構築するフローグラフを作成する可能性があります。フローグラフの作成で発生する最も一般的なエラーの一部を以下に示します。- 作成または割り当てられていない SHAPE オブジェクトへの参照
- 無効なコマンドまたはパラメーター
- ミックス バッファーの入出力参照カウントの精度
- 既存のミックス バッファー仮想 ID の再割り当て
- SHAPE コンポーネント間の接続ミックス バッファーの省略
- ステレオ コンテンツをレンダリングする際に 2 つのミックス バッファーにルーティングできる SRC ブロックを除き、SHAPE コンポーネントの出力として複数のミックス バッファーの使用
- ミックス バッファーでの循環参照 ミックス バッファーは、そのすべての入力が提示され、出力が消費されるまで利用可能になりません。ミックス バッファーで循環参照が発生している場合、そのミックス バッファーには実質的に無限の入力があり、利用可能になることはなく、グラフがハングします。
- 孤立したミックス バッファー 出力のないミックス バッファーは、最後の入力が処理されるとすぐに利用可能になります。オーディオ デバイス (スピーカーやヘッドセットなど) にレンダリングすることを意図したミックス バッファーは、DMA 出力ブロックで終端する必要があります。これにより、ミックス バッファーが最終ミックスのためにメイン メモリに提示されます。
コマンドの順序
ACP は、各 SHAPE コンポーネントのコマンド キューを自動的に埋めます。キューを埋めるとき、ACP はコンポーネントのエントリが空くまで、特定のコンポーネントの後続のコマンドをスキップします。 一般に、コマンドのスキップは無視できるパフォーマンス ペナルティを表します。ただし、コマンドの順序に基づいて、タイトルは SHAPE コンポーネントの次善の順序を作成する可能性があります。これにより、非フル状態のキューの 1 つ以上が他のキューで待機することになります。この待機により、フレームあたりの利用可能なインスタンス数が減ります。 図 1 は、コマンドの順序がパフォーマンスにどのように影響するかを示しています。ベスト プラクティスとして、フローグラフに示されているように、FLT/VOL コマンドを左から右にではなく、上から下に発行してください。これにより、より多くの音声を完了できます。この方法により、フローグラフの下部に示される EQ/CMP を並列に処理できます。 図 1. EQ/CMP を並列に処理してパフォーマンスを向上させるために、FLT/VOL コマンドを左から右ではなく上から下に発行する方法を示すフローグラフ。 特定のタイプのコマンド間でフローグラフの順序を決定するベスト プラクティスとして、サブミックス ステージまで、または再利用される SHAPE コンポーネントまで、音声の処理パスを深さ優先で優先させてください。次に、共通の処理順序を共有する音声の広さを優先します。 図 1 は、最適な (一般的な) アプローチは、まず一番左の列の FLT/VOL に対して FLT/VOL コマンドを作成し、次に上部のステレオ音声の 2 チャネル用に残りの FLT/VOL コマンドをピボットさせることを示しています。ミックス バッファー インスタンスの割り当て
ミックス バッファーは書き込み中はロックされます。すべての入力がミックスに寄与するまで、出力を読み取ることはできません。実装の観点から、ミックス バッファーはnumIn および numOut フィールドを使用してこれを管理します。したがって、同時に 128 を超える物理ミックス バッファーが必要なシナリオを構築することも可能です。
SHAPE はミックス バッファーを仮想化するため、高ポリフォニーであっても通常はこのシナリオで問題は発生しません。ただし、高数のミックス バッファーに同時にアクセスする必要のあるフローグラフを構築することもできます。特に、複数の音声間でサブミックスまたはマスタリングを行うミックス バッファーは、最後の音声がミックスされ、ミックス バッファーの最後の出力が後続の SHAPE ブロックによって消費されるまでロックされます。
一般的なシナリオ (すべての SHAPE 音声がミックスされる単一の 7.1 マスタリング音声) では、128 のうち 8 つの音声がフレーム全体を通じてロックされます。フローグラフの依存チェーンを伴う広範なマルチチャネル サブミックスがある場合、追加のミックス バッファーがフレームの大部分でロックされる可能性があります (仮想ミックス バッファーの容量が減少)。あるいは、たとえば、4 プレイヤー タイトル用にプレイヤーごとのメイン スピーカーと 7.1 ヘッドセット ミックスの両方を作成する場合、追加のマスタリング音声が作成され、40 の同時ミックス バッファーを消費する可能性があります。
一般に、128 を超える同時物理ミックス バッファーが必要なケースは病的です。ただし、フレーム全体で不必要にロックされているミックス バッファーは、タイトルが潜在的なスループットを達成する能力を低下させます。図 2 は、特定の時点で利用可能なミックス バッファーの数を減らす可能性のある不必要なサブミックスを表しています。
コマンドの順序 (図 2) によっては、5 つの独立した 7.1 マスタリング ミックス バッファーがフレームのほぼ全体を通じてロックされる可能性があり、これは物理ミックス バッファー 128 のうち 40 に相当します。このパスでは、一度に他のミックス バッファー 2 つのみ (FLT/VOL または EQ/CMP のペア入出力) を使用する必要がありますが、まずスピーカーに向かうすべてのミックス バッファーを処理することを検討してください。その後、それらのミックス バッファーを解放し、ヘッドセット 1、2、およびそれ以降を処理できます。
図 2. コマンドの順序が不適切なため、割り当てられたミックス バッファー インスタンスの不必要なサブミックスとロックを示すフローグラフ。
SHAPE コンポーネントの選択とバランス (FLT/VOL と EQ/CMP)
同じ SHAPE コンポーネントを連続して繰り返し使用すると、最大スループットに到達する能力が低下する可能性があります。比較すると、異なるコンポーネントを交互に使用することで、各 SHAPE ブロックが意味のある並列処理を行うことを保証できます。 図 3 は、一般的な例を示しています。すべての FLT/VOL を並列に処理することはできず、パフォーマンスが低下する可能性があります。 図 3. すべての FLT/VOL を並列に処理しようとするフローグラフ。 FLT/VOL の 2 番目のセットは、他の SHAPE ブロックが未使用のままである可能性があるにもかかわらず、1 番目のセットが完了するのを待つ必要があります。どちらかのセットがフィルタリングのみに使用されている場合、EQ/CMP はどちらかのセットにとってより良い選択肢を表す可能性があります。特に、同じ構成のフローグラフ (図 4) にさらに多くの音声がある場合。これにより、1 番目のセットが EQ/CMP ブロックを処理している間に、そのセットが FLT/VOL を開始できます。 図 4 は、SHAPE の理想的な機能により近いパフォーマンスを示しています。このフローグラフは、フィルタリングのみに使用されると想定される 1 セットの FLT/VOL (図 3 を参照) を EQ/CMP に置き換え、2 つの SHAPE コンポーネントの並列処理を可能にします。 図 4. FLT/VOL と EQ/CMP を並列に処理しようとするフローグラフ。 SHAPE コンポーネントのバランスは、さまざまなコンポーネントの最大インスタンス化を検討する際にも関連します。フレーム内で発生できる 2560 の FLT/VOL コンポーネントにより、FLT/VOL ハードウェアは 512 の EQ/CMP ブロックで可能な計算のおよそ 5 倍を実行できます。 EQ/CMP ブロックを単一の FLT/VOL と直列に実行すると、EQ/CMP と組み合わせて複数の FLT/VOL コンポーネントを実行するよりもパフォーマンスが低下します。前者の処理は後者の消費によってゲート制限されるためです。低価値の DMA ラウンドトリップが多すぎる、または頻繁すぎる
DMA は、SHAPE のバスで利用可能な読み書き帯域幅に束縛されます。利用可能なすべての帯域幅を消費すると (通常このシナリオは病的ですが)、DMA ブロックが停止してスループットが低下します。 前述のとおり、DMA 入力ブロックの後で発生するすべての処理は、DMA が完了するまで待機する必要があります。したがって、フローグラフの大部分がブロックされ、フローグラフの処理を開始する前に DMA が完了するのを待つフローグラフを作成できます。 DMA ラウンドトリップも、それらがオーディオ ストリームに提供する価値との関係で評価する必要があります。レイテンシーの最小限の追加 (2.667 ms のオーディオ フレーム サイズの倍数で DMA を介してアクセスされるフレーム数に関して制御可能) は、ほとんどのオーディオ再生シナリオでは懸念事項ではない可能性があります。これは、DMA の右側のブロックが前のフレームのオーディオ データを処理するためです。特に、最終ミックスも DMA としてメモリに送り返してオーディオ エンドポイントに提示することを計画している場合、単に最終ミックスを実行するために DMA を SHAPE に送り返すことは不要な可能性があります。 図 5 は、CPU/GPU 処理のために DMA を介してメモリに送信された音声が SHAPE に戻され、単にマスタリング ミックスに 7.1 パンされる、潜在的に低い価値の例を示しています。その後、音声は DMA を介してメモリに送り返されます。図 5 は、FLT/VOL ブロックの音声にフィルタリングが適用されておらず、7.1 マスタリング ミックス バッファーに追加の音声がルーティングされていることを前提としています。 図 5. 不要な FLT/VOL コンポーネントと不要な DMA ラウンドトリップを含む、潜在的に低い価値のルーティングを示すフローグラフ。 図 6 は、図 5 の意図をより最適に近くルーティングしたものです。音声は CPU/GPU 処理のために DMA を介してメモリに送信されます。その後、音声を CPU 自体で 7.1 パンして 7.1 ミックスの残りと組み合わせることができ、追加の DMA、追加のオーディオ フレーム レイテンシー、または 7 つの FLT/VOL コンポーネントの使用によるオーバーヘッドは発生しません。 図 6. 追加の DMA ラウンドトリップまたは不要な FLT/VOL コンポーネントなしのより最適なルーティングを示すフローグラフ。 プロセスから DMA を削除するとき、削除しすぎないようにしてください。ラウンドトリップ DMA の使用を正当化できるのは、次の場合です。- 特定の音声に対して大量の追加 SHAPE 処理を実行するつもりである。
- ミックス バッファーによって提供されるハードウェア メータリングとクリップ検出を活用したい。
SHAPE フローグラフの計画とレビュー
演習として、実装の前に、フレーム内で予想される音声使用のフローグラフを視覚的に表現し、音声をカテゴリ分けして数値化してみてください。たとえば、効果音の数と音楽の同時ストリーム数などで表します。 この情報を視覚的にキャプチャすることで、前述のパフォーマンスの落とし穴のいくつかを回避する方法を理解しやすくなります。以下は、そのようなフローグラフから導き出せる主要な指標のいくつかです。-
各 SHAPE コンポーネントの、同時および全体フレーム内での最大数:
- このフローグラフが理論上のピークを十分に下回っていることを確認します。
- コンポーネントの過少使用および過剰使用に注意します。必要に応じてコンポーネントの再バランスを行います。
- フローグラフの大部分を通じてロックされたままのミックス バッファーが多すぎる場合は、ミックス バッファーの使用の再構築を検討します。
-
SHAPE を介した 3D 位置決めの実装計画:
- すべての音声が 7.1 パンされるのか、それとも 2 つまたは n 個の最も近いスピーカー間でパンされるのか?
- すべての 7.1 パンニングを SHAPE で行うべきか、それとも既に DMA を介して CPU に送信されている音声は CPU 自体でパンする方が良いか?
- メモリとの間の DMA 遷移の数、およびこれらの遷移が非対称かどうか。たとえば、一部の音声は他の音声よりも多く SHAPE に書き込まれたり読み出されたりします。つまり、追加のレイテンシーが発生する可能性があります。
永続的なフローグラフと非永続的なフローグラフ
フローグラフを、永続的または非永続的として処理されるように送信できます。 永続的なフローグラフは処理された後、次のフレームで読み書きポインターが進んで他のコンテキスト情報が更新された後にその処理を繰り返すために常駐したままになります。次のいずれかのシナリオでは、永続的なフローグラフを使用してください。- 非常に複雑なフローグラフ: 各フレームを再組み立てするために大量の CPU 処理が必要なフローグラフ
- 非常に静的なフローグラフ: 長期間にわたって同じ音声の数と構成を維持するフローグラフ
- 音声トポロジが頻繁に変わる。
- タイトルのオーディオ ソフトウェア エンジンの処理ケイデンスが SHAPE ハードウェアから切り離されている。つまり、2.667 ms の倍数ではない。
- リアルタイムより速いシナリオでオーディオ処理を実行したい。つまり、利用可能になり次第、消費されるようにグラフを送信したい場合。
SHAPE の問題のデバッグ
フローグラフを開発している際に、問題のデバッグに役立つメッセージを登録することをお勧めします。具体的には、IAcpHal::Connect メソッドのNumMessages パラメーターを使用してください。
メッセージ システムは、無効なフローグラフ (ACP_FLOWGRAPH_TERMINATED_REASON_INVALID_GRAPH など)、ブロックされたコマンド、ハードウェア フレーム サイズ 2.667 ms が許可する以上の処理を実行しようとしたことによるフレーム アウトなど、さまざまな問題に関する豊富なフィードバックを提供します。
この方法はデバッグに役立ちます。ただし、タイトルを出荷する前に、以下を試みてください。
- 実行時シナリオからすべてのエラーを示すメッセージを排除します。
- 送信された各フローグラフの
ACP_MESSAGE_TYPE_FLOWGRAPH_COMPLETEDメッセージ (ACP_MESSAGE_TYPE 列挙型を参照) を確認して、フローグラフ処理が一貫して成功していることを確認します。
見逃されたメッセージ
エンジンの状態を駆動するために ACP メッセージを使用し、大量のメッセージを処理する場合は、開発中にACP_MESSAGE::droppedMessageCount を検査してください。ゼロ以外の値は、メッセージ キューがいっぱいで、メッセージがドロップされる必要があったことを示します。この値が発生した場合は、キューをより速くサービスし、より大きくすることを検討してください。
フレーム アウト
開発中、過剰な予算、次善のフローグラフ、およびその他の理由により、オーディオ フレーム (2.667 ms) の終わりに遭遇する前にフローグラフが完了しない場合があります。この不完全なフローグラフは、永続的なフローグラフに対してACP_FLOWGRAPH_TERMINATED_TIME_EXCEEDED メッセージを発生させます。それらは不完全になります。対照的に、非永続的なフローグラフはこの方法で制約されず、フレームをまたいでも完了するまで実行されます。
ブロックされたコマンド
以下の表に示すように、いくつかのシナリオで SRC および DMA コマンドがブロックされたとして報告される場合があります (ACP_MESSAGE_TYPE_SRC_BLOCKED および ACP_MESSAGE_TYPE_DMA_BLOCKED (ACP_MESSAGE_TYPE 列挙型を参照))。
コマンドがブロックされていると判断されると (処理のために SHAPE キューに項目が追加される前と実行時の両方で発生する可能性があります)、コマンドはグラフから追い出されます。これにより、オーディオがドロップされる可能性があります。開発中は、フローグラフの処理の改善を最初に検討する場所として、ブロックされたコマンドを使用してください。出荷前に、タイトルはコマンドのブロックも防止する必要があります。
DMA コマンドのブロックを防ぐには、オーディオ バッファーが十分に大きく、バッファー サイズに対して定期的な間隔でデータがストリーミングされていることを確認してください。たとえば、一度に 4 つのハードウェア フレームをストリーミングしている場合、それらのフレームの倍数 (少なくともダブル バッファーとして 8) がバッファー内にあり、ハードウェアがタイトルの読み取りポインターの先を書き込めるようにしてください。あるいは、消費し、DMA 読み取りポインターを更新し、次にフローグラフを送信することにより、次のフローグラフを送信する前にバッファーを空にすることを強制することもできます。
SRC コマンドには、次の 3 つのモードがあります (ShapeSrcContext.h で詳述)。
-
SHAPE_SRC_COMMAND_TYPE_STARTフローグラフのほぼすべての SRC コマンドに使用します。通常どおり処理し、現在のフローグラフの後に続くオーディオ データがあることを予期します。 -
SHAPE_SRC_COMMAND_TYPE_STOP_IMMEDIATEソース XMA または PCM データの処理を直ちに停止するために使用します。SRC はこのフレームに対してゼロ化されたバッファーを出力します。 -
SHAPE_SRC_COMMAND_TYPE_STOP_END音声の最後のパケットを示すために使用します。STOP_ENDまたはSTOP_IMMEDIATEで送信されない場合、SRC コマンドは完了しません。これにより、アクティブなフローグラフが停止します。永続的なフローグラフはオーディオ フレームの終わりで終了し、非永続的なフローグラフは決して完了しません。