2016-07-17 9 views
1
Clip clip = AudioSystem.getClip(); 
AudioInputStream a = AudioSystem.getAudioInputStream(new File(path)); 
clip.open(a); 

これは私のプログラムでオーディオを再生するために使用しているコードです。 Javaのプロファイリングから、私は平均してclip.open()コールが1ミリ秒以下かかることがわかります。しかし、時々ランダムな時間にそれは遅れを引き起こす数秒間ブロックします。clip.open(AudioInputStream)が数秒間ハングアップすることがあります

次のスクリーンショットは、私のJavaプロファイラを示しています。ご覧のように、まったく同じメソッドは316回呼び出され、問題はありません。しかし、Clip.open()で2.4秒間、1回ハングします。

時間が費やされた時間が0.1ms未満であるため、Clip.openがどのように下部に表示されないことに注意してください。

私が再生しているクリップのサイズはすべて約100KBです。なぜそれがうまく動作するのか分かりませんが、316コールが1回ハングします。

Profiler

私はまた、その後も問題が引き続き発生クリップを閉じますが、オープンそれらすべてを残していない試みました。

答えて

0

通常、プログラマーは.open()を使用して、いつ再生するのかを事前に確認してください。再生の瞬間には、.play()コマンドだけが必要です。連続したコマンドでクリップを「開く」と「再生」すると、play()コマンドが実行される前にファイル全体がメモリにロードされなければならないため、play()がかなり遅れることがあります。このため、Clipのメモリを確保できない場合、SourceDataLineは、play()が実行される前にバッファの値をメモリにロードするだけで済むため、より迅速に実行されます。

おそらく、あなたは既にクリップのその側面について知っていて、それは問題ではなかったでしょう。 (あなたはそれらを閉じずにクリップを演奏すると言います)。Javaのもう一つの事実は、リアルタイム保証がないということです。このシステムは、ファイルやクリップの再生を維持するのには効果的ですが、正確な開始点を制御するのは難しいです。これは、いくつかの要因の1つが、複数のスレッドとプロセスのジャグリングに費やされる時間のためです。たとえば、ガベージコレクションコマンドがサウンドコールの直前にコールを取得した場合、サウンドはそのセグメントが完了するまで待たなければならず、プロセッサはサウンドスレッドに優先順位を与えます。

だけでなく、次の紙にレイアウトされているだけでなく、リアルタイムのパフォーマンスに影響を与える他の要因があります:Real Time Low Latency Processing in Java

は、あなたの目標が何であるかに応じて、改善するために音のスレッドを利用する方法がありますその処理を行っている操作から、特定のサウンドフレームが処理のためにアップされているときに「サウンドフレームをカウントする」およびイベントを実行することによって、タイミング精度を向上させる。しかし、一般に、オーディオと他のスレッドとの間の通信は、いくつかのジッタの影響を受けます。

関連する問題