モダン スタンバイ プラットフォームに対するオーディオ サブシステムの電源管理

すべての Windows PC にはオーディオ サブシステムがあり、ユーザーはリアルタイムで高品質なサウンドを聞いたり録音したりすることができます。 コネクト スタンバイ電力モデルをサポートするハードウェア プラットフォームは、通常は、組み込みの低電力オーディオ処理ユニットを備えた System on a Chip (SoC) 統合回線を中心に構築されます。

オーディオ処理ユニットは、SoC のメイン プロセッサからオーディオ処理をオフロードします。 これらのユニットはメイン プロセッサを使用せずにオーディオ データを処理することができるため、メイン プロセッサがバッテリ電力を節約するために低電力状態に入った後でも、ユーザーはオーディオを聴き続けることができます。

このビデオでは、Windows パフォーマンス アナライザー (WPA) を使用して、スクリーンオフ オーディオ再生 (低電力オーディオまたは LPA とも呼ばれる) 中にコンピューターが低電力状態に入ることを確認する方法を紹介します。

次の記事では、コネクト スタンバイ プラットフォームのオーディオ サブシステムの電源管理について説明します。 次の説明では、on-SoC コンポーネントという用語は、SoC チップに統合されているコンポーネントを示しています。 off-SoC コンポーネントは、SoC チップの外部にあります。

オーディオ サブシステムの概要

オフロードされたオーディオ処理を実行する SoC 関数ブロックに加えて、接続されている各スタンバイ プラットフォームには、コーデック と呼ばれる off-SoC コンポーネントが含まれています。このコンポーネントは次の処理を行います。

• デコードされたデジタル ストリームをアナログ サウンドに変換します。
• 内蔵スピーカーを駆動します。
• 外部に取り付けられたアナログ ヘッドホンを駆動します。

カメラ サブシステムと同様に、オーディオ サブシステムは on-SoC コンポーネントと off-SoC コンポーネントの両方を備えます。 ただし、Windows が、On-SoC オーディオ処理エンジンと off-SoC コーデックの両方を管理する 1 つのオーディオ ドライバーを必要とします。 この 1 つのオーディオ ドライバーは、SoC に統合されているコンポーネントと、システム インテグレーターが選択できる off-SoC コンポーネントの両方を管理する役割を担います。 そのため、システム インテグレーターは、オーディオ サブシステムの統合と電源管理について SoC シリコン ベンダーと密接に連携する必要があります。

オーディオ ハードウェア ベンダーは、オーディオ ドライバーをポート クラス (Portcls) ミニポート ドライバーとして実装する必要があります。 オーディオ ドライバーが連動して動作する Portcls システム ドライバー、 Portcls.sys は、Windows の受信トレイ コンポーネントです。

他のデバイス クラスと比較して、オーディオ サブシステムがユニークなのは、プラットフォームがコネクト スタンバイ電源状態 (つまり、画面がオフになっているとき) のときに電源管理を行う点がです。 プラットフォームがコネクト スタンバイのとき、システムはオーディオ サウンドを発して、ユーザーにイベント (新しい電子メールの到着など) をリアルタイムで通知できます。 さらに、ユーザーはシステム ディスプレイをオフにしてから、オーディオがアプリケーションにより再生されるのを聴き続けることができます。 これらの機能は、システムがコネクトスタンバイ状態のときにオーディオ サブシステムをオフにしなければならない単純な電源管理方式では実現できません。 代わりに、オーディオ サブシステムの電源管理をいつでも (システムが ACPI シャットダウン (S5) 状態にあるときを除いて)、ランタイム アイドル ベースで行なわなければなりません (必要なときだけオンになるように)。

オーディオ ドライバーは、Windows オーディオ インフラストラクチャおよび PortCls システム ドライバーと密接に連携して、ランタイム アイドル電源管理を実行します。 PortCls は、オーディオ デバイスのすべてのアクセス (I/O やプロパティ アクセスなど) を監視し、アクセスごとにアイドル タイマーをリセットします。 アイドル タイマーが切れた場合、PortCls は、オーディオ デバイスを (オーディオ ドライバーの支援を受けて) 低電力スリープ (D3) 状態に移行させます。 PortCls は、新しいアクセス アクティビティが発生した場合に、オーディオ デバイスをアクティブ (D0) 状態に戻します。

また、PortCls はWindows power framework (PoFx) に登録して、オーディオ デバイスの電源状態の変更がシステム電力エンジン プラグイン (PEP) に通知されるようにします。 これらの通知により PEP は、オーディオ処理ユニットと他の SoC 関数ブロックとの間で共有されているかもしれないクロックとパワー レールをいつ、安全にオフにできるかを知ることができます。

オーディオ サブシステムを使用していないときは、オーディオ サブシステムによる消費電力が合計で 1 ミリワット未満であるスリープ状態にすることをお勧めします。 この合計には、オーディオ処理ユニット、off-SoC コーデック、および追加のオーディオ回路 (スピーカーやヘッドホンのアンプなど) によって消費される電力が含まれます。

オーディオ サブシステムのハードウェア トポロジ

オーディオサブシステムは、複数の on-SoC および off-SoC コンポーネントで構成されていますが、ACPI 名前空間では 1 つのデバイスとして Windows に提示されます。

オーディオ処理ユニットは、SoC にあります。 さまざまなベンダーから提供されている SoC が持つオーディオ処理ユニットは、それぞれの能力、消費電力、パフォーマンスにおいてさまざまです。 オーディオ処理ユニットは、オーディオ オフロードを実行する際に—メイン プロセッサを使わずに、オーディオ ストリームを処理 (オーディオ エフェクトをミキシングして適用するなど) します。 遅延時間を問題にしないオーディオ再生の場合、メイン プロセッサからのオーディオ オフロードが望ましいのは、オーディオ処理ユニットのほうがメイン プロセッサより電力消費量が少ないからです。

オフロード オーディオの詳細については、「ハードウェア オフロード オーディオ処理」を参照してください。

このシステムには、デジタル オーディオ ストリームをアナログ出力に変換して内蔵スピーカーや外部ヘッドホンを動かす off-SoC オーディオ コーデックも含まれています。 コーデックには、スピーカーとヘッドホン用の統合アナログ アンプが含まれることもあります。 または、ディスクリート アンプを代わりに使用することもできます。 一般的なコーデックには、on-SoC オーディオ処理ユニットとの次の接続があります。

• デジタル オーディオ インターフェイス (I2S または同様のシリアル バス)。
• コントロール インターフェイス (通常は I2C または類似のシリアルバス)。
• 電源管理回路を制御し、コーデック状態が変化したときに SoC を割り込みするための 1 つ以上の GPIO ピン。

これらの接続を次のブロック図に示します。

Windows の観点から見ると、オーディオ処理ユニットとオーディオ コーデックの組み合わせによって、オーディオ デバイスが構成されます。 オーディオ デバイスは、ACPI 名前空間で 1 つのデバイス オブジェクトとして列挙しなければなりません。

オーディオ サブシステムは Windows に 1 つのオーディオ ドライバーを介して公開するべきですが、SoC ベンダーが 1 つの選択肢として採用するドライバー拡張モデルでは、オーディオ ドライバーは複数の個別のドライバーに分解されます。 たとえば、オーディオコーデックを直接管理するコントロールソフトウェアは、メインのオーディオ ドライバーと切り離されたコーデック ドライバーに置かれる場合があります。 そうするとメインのオーディオ ドライバーは、コーデック ドライバーとやりとりすることによってコーデックを間接的に管理します。 このドライバー拡張モデルの詳細についてはこのドキュメントでは説明しておらず、SoC ベンダーのオーディオ ライバーによって所有されています。 システム インテグレーターは、SoC シリコン ベンダーと直接に連携して、このような独自機能をオーディオ サブシステムに実装する必要があります。

電源管理モード

オーディオ サブシステムは、次の 2 つの電源管理モードをサポートしている必要があります。

• ユーザーのためにオーディオがアクティブにストリーミングされるアクティブ モード。
• オーディオ処理ユニットがオフになっていて、off-SoC コーデックは低電力モードになっており、結合されたオーディオ サブシステム コンポーネントの消費量が 1 ミリワット未満の低電力スリープ モード。

次の表は、この 2 つの電力モードについて説明しています。

一部の SoC 設計では、オーディオ処理ユニットは、ビデオ デコードやグラフィックス処理と共有される多機能ブロックです。 これらの設計では、オーディオがアクティブにストリーミングしていないときオーディオ処理ユニットの電源がオンになるシナリオが考えられます。

ソフトウェア電源管理のメカニズム

オーディオ サブシステムの主要ソフトウェア電源管理メカニズムは、PortCls に組み込まれているランタイム アイドル検出です。 ランタイム アイドル検出によって PortCls はアプリケーション オーディオ ストリーミング アクティビティを監視して、オーディオ デバイスのアクティブ モードとスリープ電力モードを切り替えるタイミングを決定できます。 PortCls によって、オーディオ処理ユニットのパフォーマンス状態を管理するためのオーディオ ドライバーと SoC ベンダー提供パワー エンジン プラグイン (PEP) との間の独自の拡張メカニズムが可能になります。

ランタイム アイドル検出

オーディオ サブシステムのコンポーネントは、オーディオ サブシステムが指定されたタイムアウト期間アイドル状態になると、低電力スリープモードになります。

SoC ベンダーが提供するオーディオ ドライバーは、次の 2 つの既定アイドル タイムアウト設定を登録する必要があります。

• PerformanceIdleTime – ハードウェア プラットフォームが AC 電源に接続されている場合は、このタイム アウト間隔を使用します。
• ConservationIdleTime – プラットフォームがバッテリ電源で実行されている場合は、このタイム アウト間隔を使用します。

アイドル タイムアウトの設定が格納されているレジストリ エントリは、オーディオ ドライバーの PowerSettings レジストリ キーの下にあります。 詳細については、「オーディオ デバイス クラスの無通信タイマーの実装」を参照してください。

次の .inf ディレクティブを使用して、1 秒の PerformanceIdleTime タイムアウトと 1 秒の ConservationIdleTime タイムアウトを設定する必要があります。

[MyAudioDevice.AddReg]
HKR,PowerSettings,ConservationIdleTime,1,01,00,00,00
HKR,PowerSettings,PerformanceIdleTime,1,01,00,00,00
HKR,PowerSettings,IdlePowerState,1,03,00,00,00

PortCls は、AC 電源とバッテリ電源の間でプラットフォームが移行するときに PerformanceIdleTime と ConservationIdleTime のタイムアウト値を自動的に切り替えるために、Windows のカーネル電源マネージャーと協力します。

システムがコネクト スタンバイ状態 (つまり、画面がオフになっている状態) で、オーディオ再生が開始していないとき、PortCls は、アダプター ドライバーが .inf ファイルで指定しているタイムアウト設定に関係なく、常に 1 秒のアイドルタイムアウトを使用します。

SoC ベンダが提供するオーディオ ドライバーは、アイドルタイムアウトが経過したときに電源が移行する状態を指定するための IdlePowerState 設定も登録する必要があります。 すべてのコネクト スタンバイ プラットフォームで、オーディオ ドライバーが D3 を、アイドル タイムアウトが発生したときになる電源状態として、登録する必要があります。 D3 状態を指定するために、前の例の AddReg ディレクティブは IdlePowerState 値を 03 に設定します。

アイドルタイムアウトが経過すると、PortCls はオーディオドライバーの IAdapterPowerManagement3::PowerChangeState3 メソッドを呼び出して、オーディオ デバイスが低電力のスリープ モード (NewPowerState = PowerDeviceD3) に入る準備をするようにドライバーに指示します。 オーディオ ドライバーは、オーディオ処理ユニットのコンテキストを確保して、コーデックを、消費電力が平均で 1 ミリワットに満たない低電力スリープ モードにする必要があります。 低電力スリープ モードでは、コーデックはオーディオ ジャックの挿入/取り外しを検出し、SoC のメイン プロセッサにレベルトリガー割り込みを発生させるだけの電力を確保し続けていなければなりません。

アプリケーション ストリーミング、システム サウンドの生成、またはコネクト スタンバイ中の音声通知によってオーディオ再生が必要な場合、PortCls はオーディオ ドライバーの PowerChangeState3 メソッドを呼び出して、アクティブな (D0) 電源状態 (NewPowerState = PowerDeviceD0) で動作するようにオーディオ デバイスを構成するようにドライバーに指示します。 オーディオ ドライバーはオーディオ処理ユニットのコンテキストを復元し、コーデックを再び有効にする必要があります。

PortCls は、オーディオ ドライバーの IAdapterPowerManagement3::D3ExitLatencyChanged メソッドを呼び出して、スリープ (D3) 状態からアクティブ (D0) 状態への移行に許容される最大待機時間の変化をドライバーに通知します。 PortCls は、オーディオ ドライバーの D3ExitLatencyChanged メソッドを呼び出して、最大待機時間を 35 ミリ秒または 300 ミリ秒に設定します。 オーディオ ドライバーは最大待機時間の許容範囲を考慮する必要があり、 D3ExitLatencyChanged メソッドで PortCls によって指定された値よりも大きい再開待機時間を必要とする低電力状態になることはありません。

コーデック電源管理

SoC ベンダーによって提供されるオーディオ ドライバーは、off-SoC オーディオ コーデックの構成と電力管理も担います。 通常、このドライバーは、SoC からの I ² C またはその他の単純な周辺機器バス (SPB) 接続を介してオーディオ コーデックを制御します。 ドライバーは、コーデック デバイスからの割り込みも処理しなければなりません。

オーディオ サブシステムが D3 (スリープ) 状態になったら、オーディオ ドライバーはコーデックを低電力スリープ モードに移行する必要があります。

オーディオ サブシステムが D0 (アクティブ) 状態になったら、オーディオ ドライバーはコーデックをアクティブ電力モードに移行する必要があります。

Windows power framework (PoFx) とパワー エンジン プラグイン (PEP)

PortCls は Windows の電源管理フレームワークに登録します。これにより、SoC ベンダーが提供する PEP は、アクティブな (D0) 電源モードとスリープ (D3) 電源モード間のオーディオ デバイスの移行を通知されます。 多くの SoC 設計では、オーディオ処理ユニットのクロックとパワー レールは、他の on-SoC 機能ブロックと共有されます。 SoC ベンダーによって提供される PEP は、SoC 固有のクロックおよび電源トポロジを認識し、クロックを停止したり、オーディオ処理ユニットがスリープ モードのときに関連付けられているパワー レールを無効にしたりするための適切なアクションを実行します。

また、PortCls は、オーディオ ドライバーが PEP と直接通信してきめ細かな電源管理を実行できる、 コンテキスト共有と呼ばれるプライベート メカニズムをサポートしています。 たとえば、オーディオ ドライバーはコンテキスト共有を使用して、現在のオーディオ ストリームのコンテンツの種類とビットレートを PEP に通知できます。 PEP はこの情報を使用して、オーディオ処理ユニットのクロック周波数を、現在のオーディオ ストリームをグリッチなしで処理するために必要な最小値までスケールダウンします。

コンテキスト共有インターフェイスは GUID 識別子を持つ単純な入出力バッファーとして定義されており、他の拡張可能な Windows 電源管理インターフェイスと似ています。 ミニポート ドライバーと PEP 間のコンテキスト共有の詳細については、「PortCls PRIVATE PEP Context 共有」を参照してください。

サポートされているハードウェア電源構成

コネクテッドスタンバイ プラットフォームでは、Windows はオーディオ サブシステム用に 1 つのハードウェア電源管理構成をサポートします。

予想される構成では、オーディオ処理ユニットは SoC にあり、外部オーディオ コーデックは SoC と互換性のあるデジタル オーディオ インターフェイスを介して SoC に接続されます。これは、I²C などの単純な周辺機器バス (SPB) と 1 つまたは複数の GPIO ピンによって行われます。 オーディオ コーデックと外部ロジックの消費電力を、スリープ電源モードで 1 ミリワット未満にすることをお勧めします。

次のブロック図は、予想されるハードウェア構成、オーディオ デバイス ドライバー スタック、およびユーザーモード コンポーネントを示しています。

オーディオ サブシステムでは、コンポーネントをコーデックの背後に置いてオペレーティング システムとそのドライバーから認識されないようにすることができます。 たとえば、これらのコンポーネントには、スピーカーやヘッドホンのアンプが含まれます。 このようなコンポーネントはプラットフォーム固有であり、Windows 認定プログラムの一部として記載されている要件の中で、システム インテグレーターが選択できます。

システム インテグレーターは、APCI 名前空間階層のルートにある SoC オーディオ デバイスを列挙する必要があります。 オーディオ処理ユニットと外部コーデックに必要なすべてのメモリ、I/O、GPIO、I²C (または他の SPB) リソースは、名前空間のデバイスの下の _CRS オブジェクトに一覧表示される必要があります。 システム インテグレーターおよび ACPI ファームウェア開発者は、オーディオ ドライバーの開発者と話し合って、GPIO ピンなど、ハードウェア リソースの順序付けの規則を理解する必要があります。 たとえば、2 つの GPIO リソースを受け取るドライバーはそれらを、リソース リストに表示される順序に基づいて区別します。 詳細については、「GPIO ベースのハードウェア リソース」を参照してください。

ACPI ドライバー (Acpi.sys) は、デバイスの電源 IRP がオーディオ スタックを通過するときに、アクティブな (D0) とスリープ (D3) の移行を観察できますが、システム インテグレーターは、オーディオ コーデックを電源リソースの一部として記述したり、_PS0 と _PS3 の ACPI 制御メソッドを使用してコーデックの電源状態を変更したりしないでください。 スリープ モードでは、コーデックは十分に低い電力で動作して、いつでもオンのままにしてジャックの挿入と取り外しを検出できることが想定されています。

オーディオ コーデックと外部アンプは、システムが ACPI シャットダウン (S5) 状態にある場合を除き、常に電源がオンになっているパワー レールに置く必要があります。 GPIO ピンを使用して、アンプを必要に応じて有効または無効にすることができます。 アンプは、コーデックまたは SoC からの GPIO ピンを使用して制御できます。

重要な要件は、コーデック自体が電源を入れ続け— (低電力スリープ モードの場合でも)、—ジャックの挿入と取り外しを検出できる点です。 コーデックは、SoC を最も深いアイドル状態からウェイクアップする割り込みを生成してヘッドホン ジャックの挿入と取り外しを処理できる必要があります。

ウェイクの問題 (ヘッドフォンとマイクのジャック検出)

オーディオ サブシステムは、いつでも起こり得るオーディオ出力デバイスの状態の変化を処理する必要があります。 最もよくあるオーディオ デバイスの状態変化は、内蔵ヘッドホン ジャックへの出力デバイスの挿入と、このデバイスのジャックからの取り外しです。 マイクやデジタル信号ポートなど他の接続オーディオ ポートについても、ジャックの挿入と取り外しを検出する必要があります。

いつでも、オーディオ スタックはジャックの挿入と取り外しを検出できなければなりません。 オーディオ コーデックからの割り込み線は、常に電源が入っている GPIO ピンに接続されていて、いつでも SoC を最も深いアイドル状態からウェイクアップできなければなりません。 ジャック検出により Windows はオーディオ入力および出力デバイスに関する最新の情報をリアルタイムで、システムがコネクト スタンバイ状態にあるときを含めて常に維持することができます。 たとえば、ユーザーがヘッドフォン ジャックにプラグを挿入すると、直ちに Windows に通知が送られます。 この通知に対する応答として、今後接続されるスタンバイ通知アラートのサウンドは、プラットフォームの組み込みスピーカーでなく、ヘッドホンにルーティングされます。

既に説明したように、システム ファームウェアは、一連のハードウェア リソースをオーディオ デバイスに割り当てます。 これらのリソースについては ACPI _CRS オブジェクトで説明されており、オペレーティング システムはこれらのリソースの一覧をオーディオ ドライバーに渡します。 このリソース一覧には、オーディオ出力デバイスの状態変化 (ヘッドホンの挿入など) を検出するために使用されるすべての GPIO 割り込みが含まれています。 これらの割り込みは、システム ACPI ファームウェアでウェイク ソースとしてマークする必要があります。 オーディオ ドライバーは、これらのウェイク割り込みごとに割り込みハンドラーを追加する必要があります。 割り込みハンドラーはオーディオ デバイス、オーディオ コーデック、オーディオ ドライバーの状態を、必要に応じて、どの割り込みが示されているかに基づいて、更新しなければなりません。

_CRS オブジェクト内のリソースの順序のベースになっているデバイス固有の規則は、オーディオ ドライバー開発者によって定義されています。 たとえば、ドライバーが 2 つの割り込みリソースを受け取った場合、ドライバーはそれらを、リソース一覧の中の順序に基づいて見分けます。 ACPI ファームウェア開発者は同じ順序を使用して、ACPI ファームウェアでこれらのリソースを記述する必要があります。

複数のハードウェア、ファームウェア、およびソフトウェア サブシステムが連携して、オーディオ ジャックの挿入と取り外しの検出が正しく機能するようにしなければなりません。 システム インテグレーターとオーディオ ドライバー開発者は、次の実装ガイドラインに従う必要があります。

ハードウェアと SoC

• オーディオ コーデック ハードウェアは、ヘッドセット、マイク、他のジャックの挿入および取り外しイベントを、システムの電源が入っているすべての時点で、システムがコネクト スタンバイ状態にあるときを含めて、検出しなければなりません。
• オーディオ コーデック ハードウェアは、非常に少ない電力 (平均 1 ミリワット未満) を消費しながら、ジャックの挿入と取り外しを検出できなければなりません。
• オーディオ コーデック割り込みは、SoC を最も深い電力状態からウェイクすることができる SoC の GPIO ピンに接続されていなければなりません。

ACPI ファームウェア

• オーディオ デバイスは、ACPI 名前空間で記述されていなければなりません。
• ジャックの挿入を検出するために使用される GPIO 行は、ACPI ファームウェアによって排他的割り込みおよびウェイク割り込みとして記述されていなければなりません。 GpioInt 記述子マクロを使用して、Shared 引数を ExclusiveAndWake に設定します。
• オーディオ デバイスのハードウェア リソースは、オーディオ ドライバーで想定されている順序で一覧表示する必要があります。

オーディオ ドライバー ソフトウェア

• オーディオ ドライバーは、割り込みハンドラーを GPIO ウェイク割り込みに接続する必要があります。
• オーディオ ドライバーは、割り込みを処理するとき、オーディオ入出力デバイスの状態を評価して、適切なアクションを実行します。

テストおよび検証

システム インテグレーターは、Windows パフォーマンス アナライザー (WPA) を使用して、オーディオ デバイスが実行時のアイドル状態の電源管理を正しく実行し、アクティブ (D0) 状態とスリープ (D3) 状態の間で予期した状態に移行するように確認できます。 WPA は、Microsoft Connect Web サイトで提供されています。 WPA と WPA 電源管理拡張機能の入手については、Microsoft の担当者にお問い合わせください。 システム インテグレーターは、WPA 電源管理分析ツール パッケージも入手する必要があります。 このパッケージには、システム電源管理分析を可能にする WPA の拡張機能が含まれています。

WPA が依存している Windows イベント トレーシング (ETW) インストルメンテーションは、Windows カーネルおよび PortCls を含む他の Windows コンポーネントに組み込まれています。 ETW トレースを使用するために、一連のトレース プロバイダーが有効にされ、そのイベントがログ ファイルに記録されている間にテスト シナリオが実行されます。 シナリオが終了すると、トレース プロバイダーは停止します。 WPA を使用すると、テスト中のシナリオによって生成されたログ ファイルの後処理と視覚的な分析が可能になります。

WPA がインストールされているシステムでは、一連のコマンドを使用して電源管理インストルメンテーションを収集し、オーディオ デバイスの電源管理を検証できます。 Xperf.exe ツールは、\%Program Files%\Windows Kits\8.0\Windows Performance Analyzer フォルダーにインストールされます。

電源管理 ETW トレースを開始するには、コマンド プロンプト ウィンドウを管理者として開き、WPA を含むディレクトリに移動して、次のコマンドを実行します。

>xperf -start powertracesession -on Microsoft-Windows-Kernel-Power
>xperf -capturestate powertracesession Microsoft-Windows-Kernel-Power

これらのコマンドは Windows に対して、Microsoft-Windows-Kernel-Power ETW イベント プロバイダーを有効にし、Microsoft-Windows-Kernel-Power プロバイダーからイベントの初期状態をキャプチャするように指示します。

ETW トレースが開始した後、開発者はシステム シナリオを実施して、オーディオ デバイスがアクティブ (D0) 電源モードとスリープ (D3) 電源モードの間を正しく移行することを確認する必要があります。 開発者は、オーディオ デバイスを次のシナリオで検証する必要があります。

• オーディオ デバイスを D3 状態から D0 状態に移行するアプリケーションを起動します。
• すべてのオーディオ アプリケーションが閉じてから 1 秒後、オーディオ デバイスは D0 状態から D3 に移行します。
• システムがコネクト スタンバイ状態のとき、オーディオ デバイスは D3 状態のままです。
• コネクト スタンバイ中に監査通知が生成されると、オーディオ デバイスは D3 から D0 に移行し、オーディオを再生した後、1 秒後に D3 に戻ります。

これらのテスト シナリオが完了したら、次のコマンドを使用して ETW トレース収集を停止します。

>xperf -stop powertracesession -d trace.etl

WPA を使用して、結果として得られる Trace.etl ファイルを開きます。 WPA をコマンド ラインから起動するには、コマンド Wpa.exe を入力します。

WPA ツールで、グラフ エクスプローラーの一覧から [デバイスの Dstate] グラフを選択すると、次のビューが表示されます。

このビューでは、デバイスがその ACPI 名 (\_SB.AUDI など)、またはデバイス インスタンス パス (ACPI\MSFT0731\4%ffff367&2 など) で識別されます。 ACPI 名とデバイス インスタンス パスの両方が、[デバイスの Dstate] グラフの概要テーブルに一覧表示されます。

オーディオ デバイスによって行われた D 状態移行を表示するには、概要テーブルでデバイス名を見つけ、名前を右クリックして、[フィルターして選択へ] を選択します。 結果として得られるグラフには、次のスクリーンショットに示すように、オーディオ デバイスの D 状態移行だけが表示されます。

このトレース例は、オーディオ デバイスが D3 状態 (縦軸の座標 3 で示されます) で、トレースの開始から約 290 秒の 1 つの 5 秒の期間を除き、トレース期間全体を示しています。

電源管理チェックリスト

システム インテグレーターと SoC ベンダーは、次のチェックリストを使用して、オーディオ サブシステムの電源管理設計に Windows 8.1 との互換性があることを確認する必要があります。

• システム インテグレーターは、SoC ベンダーと密接に連携して、オーディオ サブシステム デバイスを統合する必要があります。

• SoC ベンダーによって開発されたオーディオ ドライバーは、次のことを行う必要があります。

  • システムが AC 電源とバッテリ電源で動いているときのランタイム アイドル タイムアウトを設定します。 オーディオ ドライバーは、PerformanceIdleTime 値と ConservationIdleTime 値の両方を 1 秒に設定する必要があります。

  • IdlePowerState 値を D3 に設定します。

  • オーディオ ドライバーの .inf ファイルで、IdlePowerState、PerformanceIdleTime、ConservationIdleTime を次の値に設定します。

    [MyAudioDevice.AddReg]
    HKR,PowerSettings,ConservationIdleTime,1,01,00,00,00
    HKR,PowerSettings,PerformanceIdleTime,1,01,00,00,00
    HKR,PowerSettings,IdlePowerState,1,03,00,00,00
    

  • PortCls がデバイスの電源状態が D3 のドライバーの IAdapterPowerManagement3::PowerChangeState3 メソッドを呼び出す場合、オーディオ ドライバーは、すべてのオーディオ処理ユニット コンテキストを保存し、コーデックを低電力スリープ モードにする必要があります。

  • PortCls がデバイスの電源状態 D0 でドライバーの PowerChangeState3 メソッドを呼び出す場合、オーディオ ドライバーは、すべてのオーディオ処理ユニット コンテキストを復元し、コーデックを再び有効にする必要があります。

  • オーディオ ドライバーは、IAdapterPowerManagement3:D3ExitLatencyChanged メソッドで PortCls によって提供される D3 終了待機時間要件に違反する電源状態を使用することはできません。

  • オーディオ ドライバーは、外部コーデックの構成と電源管理を処理しなければなりません。

  • オーディオ ドライバーは、コーデックがジャックの挿入や取り外しを検出したときに、外部コーデックからのレベル トリガー割り込みを処理しなければなりません。

• SoC ベンダーは、次の機能を備えるパワー エンジン プラグイン (PEP) を提供する必要があります。

  • オーディオ ドライバーがスリープ (D3) モードに移行したとき、オーディオ処理ユニットを低電力状態にします。
  • オーディオ ドライバーがアクティブ (D0) 電源モードに移行したとき、オーディオ処理ユニットに必要なクロックとパワー レールをオンにします。
  • オーディオ処理ユニットに提供されるクロックと電圧を、オーディオ形式、コンテンツ の種類、ビット レートに応じて、必要な処理アクティビティのレベルに従って正しくスケーリングします。

• オーディオ サブシステムのハードウェアおよびファームウェア プラットフォームを開発するために、システム インテグレーターは次のことを行う必要があります。

  • 消費電力が 1 ミリワットに満たないけれどもジャックの挿入イベントと取り外しイベントを検出できるコーデックを、スリープ モードで使用します。
  • システムが ACPI シャットダウン (S5) 状態であるときを除いて、常にオン状態であるシステム パワー レールにコーデックを配置します。
  • ACPI 名前空間階層のルートにある 1 つのデバイスとしてオーディオ サブシステムを列挙する ACPI ファームウェアを設計します。
  • オーディオ ドライバーで想定されるメモリ、割り込み、I/O、GPIO、I²C リソース順序付け規則を決定し、リソースが ACPI _CRS オブジェクトで同じ順序で一覧表示されるようにします。

• オーディオ サブシステムの電源管理をテストして検証するために、システム インテグレーターは次のことを行う必要があります。

  • オーディオ サブシステムを使用しているアプリケーションやユーザーのオーディオを生成しているアプリケーションがないときオーディオ ドライバーが D3 電源状態に移行することを検証します。
  • アイドル状態からスタンバイ状態に移行すると、画面がオフになっているときのオーディオ再生中を含め、アプリケーションまたはシステムがオーディオを生成しているときに、オーディオ ドライバーがアクティブな D0 電源状態のままであることを確認します。
  • explcit エントリからスタンバイ状態に移行すると (電源ボタンを押して、すべてのオーディオ ストリームが OS から閉じられ、アプリケーションまたはシステムがオーディオを生成しているときにオーディオ ドライバーが D3 電源状態に遷移することを確認します (OS 24H2 の新機能)。
  • Windows Hardware Lab Kit (HLK) で提供されているテストを使用して、オーディオ再生が不具合やエラーのない方法で実行されることを確認します。
  • システムがコネクト スタンバイ状態にあるときにジャック検出が正しく動作していること、ユーザーがプラグをヘッドセットのジャックに挿入したりジャックからプラグを取り外したりするとオーディオが正しくヘッドセットまたはスピーカーにルーティングされることを確認します。
  • オーディオ処理ユニット、外部コーデック、そして追加のアナログ増幅回路によって消費される電力を測定します。 オーディオ サブシステム全体がスリープ (D3) 電源状態のとき、消費する電力が 1 ミリワット未満であることを確認します。