楽しいハック講座 (4) Windows7 オーディオアーキテクチャの概要

こんにちは。日本マイクロソフトの我孫子です。今日は Windows7 のオーディオ再生・録音の仕組みについて、ハック講座らしくディープに解説していきます。

Win7 時代に ASIOは必要なのか、いわゆる「ビットパーフェクト」な再生に最適な環境は何か、などなどについて考えていく材料になればと思います。

まずは百聞は一見にしかず、ということで、図をご覧下さい。この図は、Win7 におけるオーディオの再生処理の内部動作を示しています。紙面の都合上、ここでは、「理想的な」ドライバが使われている場合のみが描かれており、「理想的でない」場合の内部動作は割愛しています。また、録音処理については大部分の矢印が逆方向になるだけですのでこちらも割愛しています。さらに、ユーザモードが詳細になっている反面、カーネルモードやハードウェアの詳細は割愛されています。それらについてはまた日を改めて取り上げる予定です。

「理想的な」ドライバとは、以下のいずれかです。

• UAA 準拠 (UAA: Unified Audio Architecture) 
  • USB 接続で Microsoft のドライバ (usbaudio.sys) を使用する場合
  • IEEE 1394 接続で Microsoft のドライバ (avcaudio.sys) を使用する場合
  • PCI バス接続でデバイスベンダー提供の HDAudio ドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得している場合
• デバイスベンダー提供のWaveRT ミニポートドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得している場合

「理想的でない」ドライバとは、以下のいずれかです。

• UAA 準拠
  • PCI バス接続でデバイスベンダー提供の HDAudio ドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得していない場合
• デバイスベンダー提供のWaveRT ミニポートドライバを使用し、かつ、そのドライバが Windows7 Certified ロゴを取得していない場合
• デバイスベンダー提供のWavePci または WaveCyclic ミニポートドライバを使用している場合

このように、Windows7 において高品質オーディオを考える上では、オーディオドライバが大変重要な役割を担っています。

Windows7 Certified ロゴを取得しているオーディオデバイスの一覧はこちらにあります。

オーディオに関わる多くのコンポーネントが XP ではカーネルモードにあったのですが、Vista ではそのほとんどがユーザーモードに移動しました。（オーディオ愛好家・サウンド製作者の間で評判の悪かった） KMixer は廃止され、オーディオエンジンにとって代わられました。これによってどこかのコンポーネントに問題が発生した場合でも OS 全体に影響を及ぼさなくなりましたので、システム全体の安定性が向上しました。デバイスベンダーの視点から言い換えますとエフェクト(APO) の開発が容易になっています。エフェクト内部で致命的な問題が発生した場合、XP では OS がブルースクリーンとなりますが、Vista 以降ではオーディオエンジンが異常終了するだけで OS 全体には影響がないようになっています。また、オーディオ愛好家・サウンド製作者の視点で言い換えますと、排他モード WASAPI を使うことによって、Windows の標準ミキシング処理（図中、オーディオエンジン内の MIX と書かれた部分）をバイパスできるようになりました。これによりレイテンシと正確性（所謂「ビットパーフェクト」）の双方にメリットがありますが、その点は後述します。

オーディオエンジンとエンドポイントバッファの間の部分がイベント駆動に対応しました。Vista でもアプリケーションとオーディオサーバの間はイベント駆動に対応していたのですが（DirectSound の互換性維持に必要だったため）、オーディオエンジンとエンドポイントバッファの間の方は Win7 以降での対応です。これと MMCSS (MultiMedia Class Scheduler Service) の改善が組み合わさったことで、Win7 ではエンドポイントバッファが空になったときだけデバイスドライバから割り込みがかかり、オーディオエンジンがオーディオサンプルをエンドポイントバッファに書き込むようになりました。当然ながら、この機能にはオーディオデバイス側の対応が必須です。Vista 時代ではこの部分が Vista Certified ロゴの必須要件ではなかったため、オーディオエンジン側もポーリングで実装せざるを得ませんでした。ポーリングでは、エンドポイントバッファが空でなくても割り込みが発生してしまうのと、余裕を持って書き込む必要があるためバッファを小さくできないので、消費電力が大きくレイテンシも長いという二重苦になっていました。Win7 ではこの問題を解決したので、Vista と比較して、共有モード WASAPI アプリケーションにおける消費電力が小さく、また、レイテンシも短くなっています。

図の中の「アドレスマッピング」という部分にご注目ください。これは、（アプリケーションが触れる）ユーザーモードのメモリ空間に存在するオーディオサンプルを、（デバイスドライバが触れる）カーネルモードのメモリ空間に直接マッピングすることによって、それらの間のコピーが不要となっている、というものです。また、今バッファ上のどの位置をハードウェアが再生しているかを示すポジションレジスタも同様にマッピングされ、アプリケーションが WASAPI を通じて直接参照できるようになっています。これには当然ながらデバイスドライバにそのような機能が必要で、前述の「理想的な」ドライバでは対応が保証されています。このおかげで、アプリケーションからデバイスドライバにオーディオサンプルが渡るまでのレイテンシが短縮されます。これは共有モード WASAPI でも排他モード WASAPI でも共通ですが、排他モード WASAPI ではもともとエンドポインドバッファにアプリケーションがオーディオサンプルを直接書き込むことができますので、これがそのままコピーなしでデバイスドライバに渡るということは、XP や Vista と比較してレイテンシをかなり短縮可能ということを意味しています。もはや ASIO は必要ない時代が到来したのかもしれません。

所謂「ビットパーフェクト」を目指す上で、排他モード WASAPI には大きなメリットがあります。APO （エフェクト）や、あるいは、オーディオエンジンの float32 (32bit単精度浮動小数点） によるミキシングで音質が低下しているのでは、といった懸念を払拭することができるからです。

さらに前述の「理想的な」ドライバでは、ドライバが自身の都合でオーディオサンプルを改変することが禁止されています。どういうことかと言いますと、オーディオデバイスが例えば内部で 12bit のみに対応していた場合、以前はドライバが 16bit → 12bit に変換してからハードウェアに渡す、といったことが許されていました（！）。前述の「理想的な」ドライバではこれが禁止されており、改変していると Windows7 Certitfied ロゴが取得できません。そのため、「理想的な」ドライバでは、排他モード WASAPI アプリケーションがエンドポイントバッファに書き込んだオーディオサンプルはそのまま1bit も変化することなくハードウェアに渡ることが保証されています。この点も「ビットパーフェクト」な再生においては重要です。（ただし、アプリケーションあるいはハードウェアがオーディオサンプルを改変している場合にはこの限りではありません。）

今回は少々毛色の異なるハック講座となりましたが、いかがだったでしょうか。Windows7 のオーディオアーキテクチャも結構頑張っていることが伝わりましたら幸いです。次回はレイテンシや「ビットパーフェクト」な再生について、Windows7 Certified ロゴ取得済みデバイスを搭載した実機で検証してみたいと思います。