4

Windowsが（少なくとも私の）マルチコアマシン（仮想ボックスではなく）でサウンドを再生すると、さまざまなプログラムの実行が0.5秒遅れることがあることに気付きました。3 つの異なるコンピューター ハードウェア構成をテストしました。また、この問題を再現するために小さな C++ テスト アプリケーションを作成しました。メモリ内の数メガバイトのナンセンスを計算し、これに費やされた時間を出力するだけです。これはループで行われるため、継続的に出力が得られます。このテスト プログラム (実行可能ファイルにマルウェアが含まれていることが心配な場合は、MinGW の GCC 4.7.2 などを使用したセルフ コンパイル用のソース コードを含む) をhttp://daiw.de/share/PrintCalculationTimes.zipにアップロードしました。

次のスクリーンショットでは、プログラムの実行中に (コントロール パネルのサウンド設定を介して) サウンドが再生されると何が起こるかを確認できます: http://daiw.de/share/PrintCalculationTimesWithoutSound.png

http://daiw.de/share/PrintCalculationTimesWithSoundWithAnnotations.png (再生ボタンをクリックするたびに発生するわけではありませんが、複数回クリックすると、テスト PC で簡単に再現できます。)

これはよく知られた問題ですか？私が提供したテストケースで誰かがこの観察を確認できますか?

ご清聴ありがとうございました。

ドビ

4

1 に答える 1

3

私が見ているのは16msのジッターであり、0.5秒の遅延ではありません。また、再生されているサウンドとは関係なく表示されます（スクリーンショットでもそうです）。

いくつかのサウンドを再生すると、（バックグラウンド優先ではない）スレッドも実行できなくなったとしたら、本当に驚きます。これは、文字通り何千ものコンピュータゲームにとって深刻な問題であり、そのすべてが常に流動的なアニメーションとサウンドの再生の両方を必要とします。

16msがシステムで使用するタイマーのデフォルトの解像度であることを考えると、結果はまったく驚くべきことではありません。それはあなたが期待しなければならないことです。

std::chrono::high_resolution_clockどちらかといえば、代わりに使用してみるかtimeBeginPeriod(1)、プログラムの先頭にaを付けてください（needs -lwinmm）。

（これにより、プログラム内だけでなく、プログラムの存続期間中だけでなくtimeBeginPeriod(1)、スケジューラがグローバルに実行される頻度が高くなります。ラップトップを使用してバッテリーで実行している場合は、バッテリーを節約するためにテスト後に再起動することをお勧めします。通常、を使用して通常の状態にリセットしendTimePeriod(1)ますが、プロセスを強制終了することが、プログラムを終了する唯一の方法であり、機能しません。）

于 2012-12-03T11:39:40.970 に答える