次の方法で共有


ハードウェアによるオーディオ処理のオフロード

ハードウェアによってオフロードされたオーディオ処理を実行すると、メイン オーディオ処理タスクをコンピューターのメイン CPU の外部で実行できます。

オーディオ処理は、計算負荷が非常に高くなることがあります。 そのため、多くのシナリオでは、専用プロセッサで、ミキシングやエフェクトの適用などの処理タスクを処理できるようにすると役立つ場合があります。

オフロード オーディオ用のドライバーを実装するときは、オフロードされたオーディオ ストリームを処理し、その機能を Windows オーディオ システムに公開できるドライバーを開発します。

このセクションの以下のトピックでは、オフロードされたオーディオ ストリームを処理するハードウェア オーディオ エンジンを実装するオーディオ アダプターのオーディオ ドライバーを開発するときに注意が必要な、ドライバーの開発、アプリケーションへの影響、その他の問題について説明します。

ハードウェアオフロードオーディオドライバの実装

オフロードされたオーディオ処理のためのヘルパー インターフェイス

オフロードされたオーディオに関するグリッチ レポート

オフロードされた API について詳しくは、「ハードウェアによってオフロードされた APO エフェクト」をご覧ください。

ハードウェアによってオフロードされたオーディオ処理アーキテクチャの概要

ソフトウェア オーディオ エンジン

次の図は、Windows ソフトウェア オーディオ エンジンを示しています。

Diagram showing audio driver architecture with application calling into SFX, MFX, and EFX effects, connecting to drivers and audio hardware.

オーディオ ストリームは、Windows オーディオ セッション API (WASAPI) レイヤーからソフトウェア オーディオ エンジンに到達し、場合によってはメディア ファンデーションなどの上位レベルの API を経由します。 ソフトウェア オーディオ エンジン ストリーム エフェクト (SFX) では、別個のストリームをミキシングした後ストリーム単位で適用してから、使用可能なエンドポイント エフェクト (EFX) を通過し、レンダリング ハードウェアとスピーカーに送信できます。

ハードウェア オーディオ エンジン

ハードウェア オーディオ エンジンはオーディオ アダプターに実装され、ソフトウェア オーディオ エンジンの機能の大部分を反映します。 また、Windows ではハードウェアによってオフロードされたオーディオ処理がサポートされていますが、特定のオーディオ アダプターのオーディオ ドライバーは、次の図に示すトポロジを使用して、オーディオ ハードウェアの基になる機能を公開する役割を担います。

ハードウェア オーディオ エンジンは、単一のホスト プロセス ストリームと最大 n 個のオフロード ストリームを受け入れる必要があります。 オフロードされたこれらのストリームは、ハードウェアで処理されるアプリケーション レイヤーから直接ルーティングされます。 つまり、オフロードされたストリームはソフトウェア オーディオ エンジンを介して渡されません。 この図は、オフロードされたストリームを最大 3 つ処理するように設計された実装を示しています。 ホスト プロセス ストリームは、ソフトウェア オーディオ エンジンで処理されたすべてのストリームのソフトウェア ミキサーからの最終的な出力です。 各ハードウェア オーディオ エンジンには、ハードウェア ミキサーも含まれている必要があります。

ソフトウェア オーディオ エンジンと WASAPI インターフェイスとのパリティを維持するため、ハードウェア オーディオ エンジンは最終的なオーディオ出力ストリームをループバック ストリームという形でオーディオ スタックに戻す必要があります。 これは、エコーを取り消してフィードバックを防ぐために最終的な出力ストリームに関する知識が必要な、音響エコー キャンセルに依存するアプリケーションやシナリオで特に重要です。

ループバック ストリームのパスを実装するため、オーディオ ドライバーはループバック ピンを公開する役割を担います。 このピンは、データが PCM 形式にエンコードされている場合、最終的なオーディオ エンジン出力からオーディオ データを返します。 それ以外の場合、ポストミキシング (ただし事前エンコード) の結果が返されます。 つまり、非 PCM 形式にエンコードするハードウェア EFX で処理されるオーディオ データの場合、ループバック ストリームはハードウェア ミキサーの直後、ハードウェア オーディオ エンジンの EFX ステージの前に取得されます。 ハードウェア オーディオ エンジンを表す KS フィルター トポロジについて詳しくは、「ハードウェアによってオフロードされたオーディオ ドライバーの実装」をご覧ください。

統合オーディオ アーキテクチャ

次の図は、ハードウェア オーディオ エンジンが Windows ソフトウェア オーディオ エンジンと連携する場合に生成されるアーキテクチャの概要を示しています。

Diagram of integrated software and hardware audio engines, with application calling into SFX, MFX, and EFX effects, connecting to drivers, audio hardware, and loopback stream leading back to WASAPI layer.

オーディオ ドライバーがオフロード オーディオ処理のサポートを示しているシナリオでは、初期化された最初の n (この場合は 3 つ) のストリームは、ソフトウェア オーディオ エンジンをバイパスして WASAPI レイヤーからハードウェア オーディオ エンジンに直接ルーティングされます。 ハードウェア オーディオ エンジンでサポートされている n 以降の新しいオーディオ ストリームは、処理のためにソフトウェア オーディオ エンジンを介してルーティングされます。 その後、ソフトウェア オーディオ エンジンから生成された結果のストリームが、ホスト プロセス ストリームとしてハードウェア オーディオ エンジンに送信されます。 ホスト プロセス ストリームが最初の n ストリームによってミキシングされて、GFX 処理が適用され、結果のストリームがスピーカーに送信されます。

KS フィルター トポロジ

Windows 8 以降のオペレーティング システムでは、オンボード ハードウェア オーディオ エンジンがオーディオ ストリームを処理するためのサポートが用意されています。 このようなオーディオ アダプターを開発するとき、関連付けられているオーディオ ドライバーは、特定の方法でユーザー モード オーディオ システムにこの事実を公開する必要があります。これにより、オーディオ システムがこのアダプターとそのドライバーの機能を検出、使用し、適切に公開できるようになります。

オーディオ ドライバーがこれらの新しいオーディオ アダプターのハードウェア機能を公開できるようにするため、Windows 8 には、ドライバーが使用する必要がある KS フィルター トポロジが導入されました。

Diagram of KS-filter topology with host process input pin, offloaded audio input pin, and loopback output pin. Audio processing applied to offloaded audio and host process pins, loopback path from final processing stage, and two streams through DAC out of the ks-filter topology.

上の図に示すように、KS フィルター トポロジは、ハードウェア経由のデータ パスを表しており、それらのパスで使用できる関数も示しています。 オフロードされたオーディオを処理できるオーディオ アダプターの場合、KS フィルターには以下の入力と出力 (ピンと呼ばれます) があります。

  • 1 つのホスト プロセス ピン。 これは、ソフトウェア オーディオ エンジンからの KS フィルターへの入力を表しています。

  • 1 つのループバック ピン。 これは、ハードウェア オーディオ エンジンから Windows オーディオ セッション API (WASAPI) レイヤーへの出力を表しています。

  • オフロードされたオーディオ ピンの数。 この図は、この種類のピンを 1 つのみ示していますが、IHV は任意の数 (n) のピンを自由に実装できます。

オーディオ アダプターとそのドライバーの検出に "導く" ユーザー モード オーディオ システムの実際のサービスは、AudioEndpointBuilder です。 AudioEndpointBuilder サービスは、デバイス インターフェイスの到着と削除で KSCATEGORY_AUDIO クラスを監視します。 オーディオ デバイス ドライバーが KSCATEGORY_AUDIO デバイス インターフェイス クラスの新しいインスタンスを登録すると、デバイス インターフェイスの到着通知がオフになります。 AudioEndpointBuilder サービスは、デバイス インターフェイス到着通知を検出し、アルゴリズムを使ってシステム内のオーディオ デバイスのトポロジを調べることにより、適切なアクションを実行できるようになります。

オフロードされたオーディオを処理できるアダプターをサポートするオーディオ ドライバーを開発する場合、ドライバーは、KSNODETYPE_AUDIO_ENGINE オーディオ エンドポイントを使用してハードウェア オーディオ エンジンの機能を公開する必要があります。 オーディオ エンドポイント検出プロセスについて詳しくは、「オーディオ エンドポイント ビルダー アルゴリズム」をご覧ください。

ユーザー インターフェイスに関する考慮事項

オフロードされたオーディオを処理できるオーディオ アダプターの基になるハードウェア機能を制御するオーディオ ドライバーを開発しました。 これは、ドライバーがアダプターの機能を制御する方法に関する最適な知識を持っていることを意味します。 そのため、エンド ユーザーが選択、有効化、無効化できるオプションの形式でアダプターの機能を公開する UI を開発する必要があります。

ただし、開発したオーディオ処理オブジェクト (API) の制御に使用される UI が既にある場合、この UI を拡張して新しいオーディオ アダプターを操作できます。 この場合、UI の拡張機能によって、APO のソフトウェア制御と、アダプターのハードウェア制御が提供されます。

アプリケーションの影響

この新しい種類のオーディオ アダプターとそれに関連付けられているドライバーに関して説明されている機能は、WASAPI、メディア ファンデーション、メディア エンジン、または HTML 5 <オーディオ> タグを通じて UWP アプリで使用できます。 Wave と DSound は、UWP アプリでは使用できないため、使用できない点に注意してください。 さらに、デスクトップ アプリケーションでは、ハードウェアによってオフロードされたオーディオをサポートするオーディオ アダプターのオフロード機能を使用できない点に注意してください。 これらのアプリケーションは引き続きオーディオをレンダリングできますが、ソフトウェア オーディオ エンジンを使用するホスト ピンを通じてのみ実行できます。

UWP アプリがメディア コンテンツをストリーミングし、メディア ファンデーション、メディア エンジン、または HTML 5 <オーディオ> タグを使用する場合、ストリームに適切なオーディオ カテゴリが設定されている限り、アプリはハードウェア オフロードに自動的にオプトインされます。 ハードウェア オフロードのオプトインは、ストリーム単位で行われます。

WASAPI またはストリーミング通信を使用する UWP アプリでは、ハードウェア オフロードを明示的にオプトインする必要があります。

ハードウェアオフロードオーディオドライバの実装

Windows オーディオ処理オブジェクト