ハードウェア オフロードオーディオ処理を使用すると、メインのオーディオ処理タスクをコンピューターのメイン CPU の外部で実行できます。
オーディオ処理は、計算負荷が非常に高い場合があります。 そのため、多くのシナリオでは、専用プロセッサで、混合や効果の適用などの処理タスクを処理できるようにすることが有益な場合があります。
オフロードオーディオ用のドライバーを実装する場合は、オフロードされたオーディオ ストリームを処理し、その機能を Windows オーディオ システムに公開できるドライバーを開発します。
このセクションの次のトピックでは、オフロードされたオーディオ ストリームを処理するハードウェア オーディオ エンジンを実装するオーディオ アダプターのオーディオ ドライバーを開発するときに注意する必要があるドライバーの開発、アプリケーションへの影響、およびその他の問題について説明します。
オフロード オーディオ の グリッチ レポート
オフロードされた API の詳細については、「ハードウェア オフロード APO 効果」を参照してください。
Hardware-Offloaded オーディオ処理アーキテクチャの概要
ソフトウェア オーディオ エンジン
次の図は、Windows ソフトウェア オーディオ エンジンを示しています。
オーディオ ストリームは、Windows オーディオ セッション API (WASAPI) レイヤーからソフトウェア オーディオ エンジンに届き、場合によっては Media Foundation などの上位レベルの API を介して受信されます。 ソフトウェアオーディオエンジンのストリーム効果（SFX）は、ストリームごとに適用され、個別のストリームがミックスされる前にこれが行われます。その後、使用可能なエンドポイント効果（EFX）を通過し、レンダリングハードウェアとスピーカーに送信されます。
ハードウェア オーディオ エンジン
ハードウェア オーディオ エンジンはオーディオ アダプターに実装され、主にソフトウェア オーディオ エンジンの機能を反映します。 また、Windows ではハードウェア オフロードオーディオ処理がサポートされていますが、特定のオーディオ アダプターのオーディオ ドライバーは、次の図に示すトポロジを使用して、オーディオ ハードウェアの基になる機能を公開する役割を担います。
ハードウェア オーディオ エンジンは、1 つのホスト プロセス ストリームと最大 n 個のオフロード ストリームを受け入れる必要があります。 これらのオフロード ストリームは、ハードウェアで処理されるアプリケーション 層から直接ルーティングされます。 つまり、オフロードされたストリームはソフトウェア オーディオ エンジンを介して渡されません。 この図は、オフロードされたストリームを最大 3 つ処理するように設計された実装を示しています。 ホスト プロセス ストリームは、ソフトウェア オーディオ エンジンで処理されたすべてのストリームのソフトウェア ミキサーからの最終的な出力です。 各ハードウェア オーディオ エンジンには、ハードウェア ミキサーも含まれている必要があります。
ソフトウェア オーディオ エンジンと WASAPI インターフェイスとの同等性を維持するには、ハードウェア オーディオ エンジンが最終的なオーディオ出力ストリームをループバック ストリームの形式でオーディオ スタックに返す必要があります。 これは、エコーを取り消してフィードバックを防ぐために最終的な出力ストリームに関する知識が必要な、Acoustic Echo Cancellation に依存するアプリケーションやシナリオで特に重要です。
ループバック ストリームのパスを実装するために、オーディオ ドライバーはループバック ピンを公開する役割を担います。 このピンは、データが PCM 形式にエンコードされている場合、最終的なオーディオ エンジン出力からオーディオ データを返します。 それ以外の場合は、ポストミキシング (ただし事前エンコード) の結果が返されます。 つまり、非 PCM 形式にエンコードするハードウェア EFX で処理されるオーディオ データの場合、ループバック ストリームはハードウェア ミキサーの直後、ハードウェア オーディオ エンジンの EFX ステージの前に取得されます。 ハードウェア オーディオ エンジンを表す KS フィルター トポロジの詳細については、「 ハードウェア オフロード オーディオ ドライバーの実装」を参照してください。
統合オーディオ アーキテクチャ
次の図は、ハードウェア オーディオ エンジンが Windows ソフトウェア オーディオ エンジンで動作する場合に生成されるアーキテクチャの概要を示しています。
オーディオ ドライバーがオフロードオーディオ処理のサポートを示したシナリオでは、初期化された最初の n (この場合は 3 つ) のストリームは、ソフトウェア オーディオ エンジンをバイパスして、WASAPI レイヤーからハードウェア オーディオ エンジンに直接ルーティングされます。 ハードウェア オーディオ エンジンでサポートされている n 以降の新しいオーディオ ストリームは、処理のためにソフトウェア オーディオ エンジンを介してルーティングされます。 その後、ソフトウェア オーディオ エンジンから生成されたストリームが、ホスト プロセス ストリームとしてハードウェア オーディオ エンジンに送信されます。 ホスト プロセス ストリームが最初の n ストリームと混在し、EFX 処理が適用され、結果のストリームがスピーカーに送信されます。
KS フィルター トポロジ
Windows 8 以降のオペレーティング システムでは、オンボード ハードウェア オーディオ エンジンがオーディオ ストリームを処理するためのサポートが提供されています。 このようなオーディオ アダプターを開発する場合、関連付けられているオーディオ ドライバーは、特定の方法でユーザー モードオーディオ システムにこの事実を公開する必要があります。これにより、オーディオ システムはこのアダプターとそのドライバーの機能を検出、使用、および適切に公開できます。
オーディオ ドライバーがこれらの新しいオーディオ アダプターのハードウェア機能を公開できるようにするために、Windows 8 では、ドライバーが使用する必要がある KS フィルター トポロジが導入されました。
上の図に示すように、KS フィルター トポロジは、ハードウェア経由のデータ パスを表し、それらのパスで使用できる関数も示しています。 オフロードされたオーディオを処理できるオーディオ アダプターの場合、KS フィルターには次の入力と出力 (ピンと呼ばれます) があります。
1 つのホスト プロセス ピン。 これは、ソフトウェア オーディオ エンジンからの KS フィルターへの入力を表します。
ひとつのループバックピン。 これは、ハードウェア オーディオ エンジンから Windows オーディオ セッション API (WASAPI) レイヤーへの出力を表します。
オフロード オーディオ ピンの数。 この図は、この種類のピンを 1 つだけ示していますが、IHV は任意の数 (n) のピンを自由に実装できます。
オーディオ アダプターとそのドライバーの検出に "導く" ユーザー モードオーディオ システムの実際のサービスは、AudioEndpointBuilder です。 AudioEndpointBuilder サービスは、デバイス インターフェイスの到着と削除の KSCATEGORY_AUDIO クラスを監視します。 オーディオ デバイス ドライバーが KSCATEGORY_AUDIO デバイス インターフェイス クラスの新しいインスタンスを登録すると、デバイス インターフェイスの到着通知がオフになります。 AudioEndpointBuilder サービスは、デバイス インターフェイス到着通知を検出し、アルゴリズムを使用してシステム内のオーディオ デバイスのトポロジを調べて、適切なアクションを実行できるようにします。
オフロード オーディオを処理できるアダプターをサポートするようにオーディオ ドライバーを開発する場合、ドライバーは 、ハードウェア オーディオ エンジンの機能を公開するためにKSNODETYPE_AUDIO_ENGINEオーディオ エンドポイントを使用する必要があります。 オーディオ エンドポイント検出プロセスの詳細については、「 オーディオ エンドポイント ビルダー アルゴリズム」を参照してください。
ユーザー インターフェイスに関する考慮事項
オフロード オーディオを処理できるオーディオ アダプターの基になるハードウェア機能を制御するオーディオ ドライバーを開発しました。 これは、ドライバーがアダプターの機能を制御する方法に関する最高の知識を持っていることを意味します。 そのため、アダプターの機能をエンド ユーザーが選択、有効化、無効化できるオプションの形式で公開する UI を開発する必要があります。
ただし、開発したオーディオ処理オブジェクト (API) の制御に使用される UI が既にある場合は、この UI を拡張して新しいオーディオ アダプターを操作できます。 この場合、UI の拡張機能によって、API のソフトウェア制御と、アダプターのハードウェア制御が提供されます。
アプリケーションへの影響
この新しい種類のオーディオ アダプターとそれに関連付けられているドライバーに関して説明されている機能は、WASAPI、Media Foundation、Media Engine、または HTML 5 <audio> タグを介して UWP アプリで使用できます。 Wave と DSound は UWP アプリでは使用できないため、使用できないことに注意してください。 また、デスクトップ アプリケーションでは、ハードウェア オフロード オーディオをサポートするオーディオ アダプターのオフロード機能を使用できないことに注意してください。 これらのアプリケーションは引き続きオーディオをレンダリングできますが、ソフトウェア オーディオ エンジンを使用するホスト ピンを介してのみ実行できます。
UWP アプリがメディア コンテンツをストリーミングし、Media Foundation、Media Engine、または HTML 5 <audio> タグを使用する場合、ストリームに適切なオーディオ カテゴリが設定されている限り、アプリはハードウェア オフロード用に自動的にオプトインされます。 ハードウェア オフロードのオプトインは、ストリームごとに行われます。
WASAPI またはストリーミング通信を使用する UWP アプリでは、ハードウェア オフロードを明示的にオプトインする必要があります。