チケット #37231

登録: 2017-05-30 22:32

最終更新: 2017-06-15 01:49

Win10での低遅延サウンド再生方式対応

報告者:yyagi担当者:yyagi
優先度:5 - 中マイルストーン:既存機能の仕様変更
チケットの種類:性能改善重要度:5 - 中
コンポーネント:FDK状況:オープン [担当者決定済み]
解決法なし

チケットの詳細

Win10では、WASAPI共有での出力遅延を10ms程度に収めるような実装が可能とのことで、これに対応する。

BASS_Mixerの出力まではBASSで扱って、最終出力を自力実装するような感じでしょうか。

添付ファイル

添付ファイルリスト添付ファイルはありません
新規添付ファイル追加
添付ファイルの追加添付ファイルの追加にはログインが必要です

チケットの履歴 - 5 件中 3 件表示 [古い履歴も表示する]

2017-05-30 22:32 更新者: yyagi

  • 新しいチケット "Win10での低遅延サウンド再生方式対応" が作成されました

2017-06-04 01:33 更新者: yyagi

コメント

まず、manifestを修正して、Win8.0互換モードで動かさないようにだけしてみました。その結果、Win10 Creators Update, オンマザーサウンドでバッファが

  • WASAPI排他: 14ms (Win8.0互換時は4msと表示されていた)
  • WASAPI共有: 44ms (Win8.0互換時は22msと表示されていた。しかし体感としては100msくらい(DirectSoundと同等って感じ) )

になりました。

なんでWASAPI排他で悪化するかなー。

一方、WASAPI共有はぎりぎり我慢できなくもないくらいの体感になりました。

2017-06-14 00:34 更新者: yyagi

  • 担当者(未割り当て) から yyagi に更新されました

コメント

その後、うちの環境で何度も実験してみましたが、どうも、manifestでWin10モードを使わないようにして、Win8.0互換で動かすようにしたほうが、バッファを小さく設定できて、動作負荷も軽いようです。(具体的な結果はひとつ前のコメントを参照ください)

Win8.0互換に戻そうかな・・・

うちの環境:

  • Win10 Pro, Creators Update, x64
  • Realtek HD Audio (ここしばらく、USB Audioを使っていません)
  • HaswellのそこそこのCPU

2017-06-15 00:05 更新者: from

コメント

おつですー。

最近WASAPIの勉強しなおしてみようと思っていろいろなサイト見てたら気づいたんですけど、(低遅延じゃない場合の)WASAPI共有のバッファサイズって「遅延」じゃないっぽいですね。

ほぼすべての技術ページで(MSDNのLowLatencyAudioでも)「latency」じゃなく「period」と言ってるので、バッファサイズから算出できるのは、WASAPI排他でいう「更新間隔」だけなんじゃないかなと。

ついでに、その「バッファ」というのも「AudioEngineのバッファ」じゃなくて「アプリのバッファ」なんじゃないかなと。

また、実測によると、WASAPI共有モードでは指定したperiodが10msであるなら、バッファのサイズが22msであっても、10msごとにイベント駆動されてるなと。

結論、共有モードの実際の遅延はやっぱり100msくらいありそうですね……

2017-06-15 01:49 更新者: yyagi

コメント

WASAPI共有について、BASS.NET APIの、BassWasapi.BASS_WASAPI_Init Methodのところを読んでみると、最後にこんなことが書いてありました。

WASAPI共有時は "it's the other way round" (periodとbufferの依存関係が逆転する)、つまりbufferサイズにperiodが影響を受けて、更に結局それはdefperiodのサイズにアラインされるということです。FROMさんのご指摘は正解のようです。

In EXCLUSIVE mode, the "period" value will affect what's an acceptable "buffer" value (it appears that the buffer must be at least 4x the period).

In SHARED mode, it's the other way round, the "period" will be reduced to fit the "buffer" if necessary (with a minimum of the "defperiod" value).

The system will limit them to an acceptable range, so for example, you could use a very small value (eg. 0.0001) for both, to get the minimum possible latency.

初期化のロジックは、WASAPIの排他と共有で、別々に作りこまないといけなさそうですね。明日にでもコードを組みなおします。

WASAPI共有のラグが結局100msくらいありそうだというのには同感です。私の体感でも、その程度だと感じています。

# しかし、いい加減、WASAPI周りをこねくり回すのにも飽きてきました(苦笑;;;


追記/更新 #37231 (Win10での低遅延サウンド再生方式対応)

ログインしていません。ログインしていない状態では、コメントに記載者の記録が残りません。 » ログインする