WASAPIのプッシュとイベントの違いがわからない。大抵のページには「どちらでも良い」と書かれている。耳で聞いてもわからないし、「まぁ良いか」ということでプッシュ・モードで聞いていた。

ところが、foobar をいじったときにこの違いが明らかになった。

そこであらためて調べて見だが、スッキリした話はどこにもない。仕方がないので英語まで手を伸ばして次の文章を手に入れた。


Hydrogenaudio Forum

というサイトに次のような発言があった。

https://hydrogenaud.io/index.php/topic,111120.0.html

Reply #2 – 31 January, 2016, 05:17:11 AM


foobar2000において、プッシュとイベントはともに排他モードで操作されている。

唯一の違いは駆動するバッファーの違いにある。あるいはバッファーの処理法の違いにある。

foobarでどちらかの方法を使うにせよ、タイマーの問題は核心ではない。

それはどのくらいのデータがバッファとして必要かにより違う。

イベント・モードではAPIドライバーによるcallback法で、より多くのデータが必要である。callbackは、前もって準備されたバッファが再生されようとする直前に点検される。

プッシュ・モードでは自らのthreadのなかにloopがあって、ドライバーに対し繰り返し新しいバッファの受け入れを尋ねてくる。またその前のバッファーにも関係する。

イベント・モードはlower latencyを期待できる。なぜなら呼び出しアプリは、新しいバッファが入る正確な時間を実現できるからだ。しかしプッシュ・モードは呼び出しアプリをその度に起動するので、デレイが生じる。

タイマー・ベースのプッシュ・モードでは、それぞれのバッファーの持続時間の間に少なくとも2回のチェックが入っていると思う。再生に入る前のチェックと次のバッファーの点検に入るためのチェックだ。なぜならこのモードでは一つのバッファーの再生時間の厳密な判断ができないからだ。


ここまで読んでもなんのことやらよう分からんが、どうやらイベント・モードは一つの曲を時間ごとに細切れにしていって、前処理していくようだ。スケジュールに合わせてどんどんスケジュールが進行していくから、遅れはないがメモリーを食う。

それに対してプッシュモードは曲の流れ具合を見ながら、「はーい、亀さん、出番ですよ」と呼び出して行くスタイルらしい。

イベントモードのほうが後から開発されたようだ。まぁ説明書を見ればイベント・モードを使いたくはなる。


質問が両者のレイテンシー比較にあったので、回答者はこう回答をまとめている.

latencyだけを問題にするなら、50msでも十分でしょう。何か特殊な作業をするのでなければ、例えば録音した音楽の再生であれば、200msecでも十分です。

どうしても減らしたいなら、WASAPIでは20msecが限界です。もしもっと低くしたいのなら、ASIOを使えば2msecまで減らすことはできます。

ことレイテンシーに関してはWASAPIはASIOに到底及ばないようだ。