http://www.jriver.com/
JRMCも音が良いミュージックプレーヤーソフトですが、特筆するものがなかったので特にうちでは扱っていませんでした。ただCAフォーラムの記事によるとWASAPIのイベント駆動に対応したということですので、今回取り上げてみました。
http://wiki.jriver.com/index.php/WASAPI
今回都合よいのでついでにOSのスケジューリングについてあわせて解説してみます。
*イベント駆動とはなにか
プログラム(この場合ミュージックプレーヤー)がオーディオデータを書き込むバッファの空きを見に行くと仮定しましょう。イベント駆動ではあるイベント(たとえばバッファが空になったということ)をOSから知らせてもらって、そのタイミングで処理をします。対して一般的にはポーリングという手法でバッファが空になったということを確認しています。これはプログラムが能動的にバッファが空になったかを見に行くということです。この場合のタイミングはプログラムが自分の番にきたときです。
ここでさきのMSDNのブログ「VistaからWin7への変更点」からその部分をちょっと引用します。
引用元アドレスはこちらです。
http://blogs.msdn.com/b/windows_multimedia_jp/archive/2010/06/28/4-windows7.aspx
----引用開始----
VistaからWin7への変更点
オーディオエンジンとエンドポイントバッファの間の部分がイベント駆動に対応しました。Vista でもアプリケーションとオーディオサーバの間はイベント駆動に対応していたのですが（DirectSound の互換性維持に必要だったため）、オーディオエンジンとエンドポイントバッファの間の方は Win7 以降での対応です。これと MMCSS (MultiMedia Class Scheduler Service) の改善が組み合わさったことで、Win7 ではエンドポイントバッファが空になったときだけデバイスドライバから割り込みがかかり、オーディオエンジンがオーディオサンプルをエンドポイントバッファに書き込むようになりました。当然ながら、この機能にはオーディオデバイス側の対応が必須です。Vista 時代ではこの部分が Vista Certified ロゴの必須要件ではなかったため、オーディオエンジン側もポーリングで実装せざるを得ませんでした。ポーリングでは、エンドポイントバッファが空でなくても割り込みが発生してしまうのと、余裕を持って書き込む必要があるためバッファを小さくできないので、消費電力が大きくレイテンシも長いという二重苦になっていました。Win7 ではこの問題を解決したので、Vista と比較して、共有モード WASAPI アプリケーションにおける消費電力が小さく、また、レイテンシも短くなっています。
----引用終了----
これはいつバッファが空になるかをポーリング(つまり能動的に見に行く)で確認していると、ポーリングとポーリングの間に空になってしまうと音が途切れてしまいますので、その間の十分な量のバッファを用意する必要があるということでしょう。この場合のバッファというのはつまり余裕時間(リードタイム)みたいなものですので、そうするとつまりレイテンシーは大きくなってしまいます。
しかし、「空になったよ」というイベントが発生したときにOSが教えてくれれば、その都度に効率よく書き込みができるので、そんなに余裕をもったバッファは必要ありません。
これがイベント駆動です。割り込みがかかることがトリガーになるのはポーリングも同じですが、ポーリングの場合はタイマーがトリガーになります。
*OSのスケジューリングとは
ここで説明が必要なのは、OS上で走る複数のプログラムはタイマーで時分割されて動いているということです。こうしてOSがCPUを管理することをプリエンプティブ方式と言います。
OSの上でプログラムがマルチタスキングで動作しているとき、複数のプログラムを順に切り替える必要があります。その切り替える順番決定をスケジューリングといいます。(ちなみにタスクというのは情報処理の言葉ではOSからみた処理の最小単位のことです)
Windowsのような汎用OSの場合はラウンドロビンという巡回方式のスケジューリングが主なんですが、この方式では仮にプライオリティが高いプログラムでも自分の順番がくるまで待たねばなりません。優先度が高いというのは単に待ち行列の前のほうに入れてもらえるということです。そのため、先の例だと自分の番に来たときにバッファの空きを都度確認するということになります。これがポーリングです。優先度を高くすればポーリングの間隔は短くなるかもしれませんが、能動的に見に行くことが必要なのは変わりありません。
また割り込み間隔を短くして自分の番にくる回数を上げようとすると、コンテキストスイッチング多発というさらなる問題が発生します。
パソコンを休止状態で落とすと状態保存するのに少し時間がかかります。これと似たようなことをプロセスが他のプロセスに制御を渡すときにも行う必要があります。これをコンテキストスイッチングといいますが、やはり時間がかかります。このOSのオーバーヘッドが多発すると、システム全体の速度が低下します。システムというのは総合的にいろいろなプログラムが動いて働いています。そのため、あるプロセスだけを異常に優先度を上げるのは得策ではありません。そこで出てくるのがMMCSSです。
*MMCSSとスケジューリング
マルチメディアとスケジューリングという点ではVista以降でサポートされたマルチメディア用の優先度設定であるMultimedia Class Scheduler service (MMCSS)があります。
これはデバイスから取得される時間属性を元に"Pro Audio"とか"Audio"あるいは"Game"などのようにアプリケーションの用途に合わせて、一時的に優先度を設定するものです。具体的にはオーディオストリーム開始前にAvSetMmThreadCharacteristicsで優先度をセットして、終わったらAvRevertMmThreadCharasteristicsで戻す、という風にします。
これはさきの排他モードのコードの例でも使われています。(MMCSSを使うときはストリームがPCMでなければならないようです)
http://msdn.microsoft.com/en-us/library/dd370844(VS.85).aspx
MMCSSはDSPのようなCPUを使う処理をしながら音途切れをさせないというような場合には有効ですが、さきの場合のレイテンシーという点で言うと、優先度を上げても、ポーリングで見に行くという点の完全な解決にはなりません。
まずいくら優先度が低いプロセス(スレッド)の優先度を下げてもゼロにはできないし(10%がミニマム)、他のプロセスにいつかは制御を渡さねばなりません。
MSDNのページでも下記のような記述があります。
MMCSS enables audio applications to run at high priority without denying CPU resources to lower-priority applications.
もともとMMCSSの目的はPCをマルチメディア専用にするのではなく、むしろ他のタスクに迷惑をかけないように共存しながら自分はマルチメディアなんだから優先度をくださいというような用途に使われるものに思えます。
それに対してイベント駆動型ではイベントがあった場合(たとえばバッファの空きが発生したとき)に即座にそのプログラム(タスク)に制御が渡されます。OSが教えてくれるわけなので、自分で見に行く(ポーリング)必要がありません。つまり受動的で無駄がありません。
ところで、イベント駆動はリアルタイムOSに見られる制御方法です。
下記リンクに説明がありますが、リアルタイムOSというのは処理が早いOSのことではありません。必要なときに必要な処理を行える仕事のスケジューリングができるOSのことです。そのためにイベント駆動のスケジューリングが使われます。
http://www.semicon.panasonic.co.jp/micom/realtimeos/feature.html
ちなみに今年の話題のひとつだった「はやぶさ」には国産のリアルタイムOSであるTRONが使われていました。
*JRMC15
こちらがJRMC15の画面です。日本語タグ名も使用ができます。
詳細は省きますが、Foobarが使えれば特にむずかしくはないでしょう。
こちらがWASAPIの設定画面です。スタート時のバッファのクリア(flush)などもあり、なかなか細かいところです。
音質はとても透明感の高い澄んだWASAPIならではの音質に加えて厚みが感じられるように思います。これもすばらしい音質です。バランスが取れていて聴きやすさも兼ね備えています。
Foobar 2000とWASAPIコンポーネントだとノイズが入ることがあり、わたしはバッファサイズを工夫して対処していますが、このJRMCのWASAPIはそういうこともなくスムーズです。
ちょっといま忙しいのであまり試せませんが、JRMCはメモリー上での再生とかネットワーク対応など試すところが多いのでまたいろいろと試してみたいと思います。
