JavaSound でクリップを再生するたびに、バックグラウンドでクリップを再生するためのスレッドが作成されることを StackOverflow で読みました。それが本当なら (そうでない場合は、そのドキュメント/ソースが見つからないので教えてください)、スレッドの作成はどの OS/JVM でも高価なタスクであるため、高価な呼び出しと見なされますか? まだわかりませんが、10 ～ 20 個のクリップを同時に再生する必要があるかもしれないので、それが問題になるのではないかと考えていました。
PS: スレッドを作成する以外の理由で外傷的な呼び出しである場合は、お知らせください。
特に、スレッドは高価ではありません。私は個人的に500以上のプログラムを実行しています。サーバー プログラムは、それよりもかなり多くのプログラムを生成できます。
サウンド処理は安価ではありませんが、3D の照明などの多くのグラフィックス効果よりも CPU を大量に消費するかどうかはわかりません。サウンドを再生し、サウンドが再生されている間に成長したり消えたりする「グローボール」を作成するプログラムを作成しました。「グロー ボール」は、この効果を実現するために RadialGradientPaint を継続的に更新しました。約 10 個のボールとサウンドの上限に出くわしましたが、処理負荷が大きかったのはグラフィック ボールでした。
それでも、17 個のクリップを再生すると、他に多くのことができない場合があります。テストする必要があり、CPU が追いつかない場合はドロップアウトが聞こえます。
17 個のクリップが大量の RAM を占有する場合があります。それらはすべてメモリにロードされていることをご存知ですか？毎秒 44100 サンプルで、通常はサンプルあたり 4 バイト (ステレオ、16 ビット PCM) で、すぐに加算され始めます。
そのため、特に長いサウンドの場合は、代わりに SourceDataLine の使用を検討する理由があるかもしれません。
また、一部の OS システムでは、複数のサウンドをうまく処理できないようです。ここでは、特に Linux で問題が発生しました。これを処理する方法として、すべての再生音を 1 つの出力 SourceDataLine にミックスするプログラムを作成することになりました。
効率を上げるもう 1 つの方法は、独自のカスタム メイドのクリップをロードすることです。このクリップには、オーディオ データを個別に移動できる複数のカーソル (ポインター) を指定しました。このようにして、クリップを複数回 (さまざまな速度で) オーバーラップして再生できます。Java Clip でこれを行うには、RAM に複数回ロードする必要があります。だから、あなたはそのようなことを書くことを考えるかもしれません。複数のカーソルからの出力は、SourceDataLine を介して合計および再生できます。