Java（JavaSound）：「clip.play（）」是一個昂貴的調用嗎？

Question

我已經閱讀了StackOverflow上的here，每當您在JavaSound中播放剪輯時，在幕後創建一個線程來播放它。如果它是真的（如果不是，請告訴我，因爲我沒有找到任何文檔/源代碼），它會被認爲是一個昂貴的調用，因爲在任何OS/JVM中創建線程是一項昂貴的任務？我還不確定，但我可能需要同時播放10到20個剪輯，所以我想知道這是否會成爲問題。

PS：如果是除了創建線程之外的其他原因的exoensive調用，請讓我知道。

Answer 1

線程並不昂貴，特別是。我親自制作了一個運行超過500次的程序。服務器程序可以產生比這更多的東西。

聲音處理並不便宜，但我不知道它比許多圖形效果更強的cpu密集，如3D照明。我製作了一個節目，既播放聲音，又製作一個「發光球」，在播放聲音的過程中，它會逐漸消失。 「發光球」不斷更新RadialGradientPaint以達到此效果。我遇到了大約10個球的天花板併發出聲音，這是圖形球的更大處理負荷。

儘管如此，你可能無法在17張剪輯播放時做很多事情。你將不得不測試它，並且如果cpu無法跟上會聽到dropouts。

您的17個剪輯可能會佔用大量的RAM。你知道他們全都加載到內存中，是嗎？每秒44100個樣本，通常每個樣本4個字節（立體聲，16位PCM），開始快速加起來。

因此，可能有理由考慮使用SourceDataLine，而不是，特別是對於更長的聲音。

另外，它似乎有些操作系統不能很好地處理多個聲音。特別是在Linux上遇到問題。我最終編寫了一個程序將所有播放的聲音混合到一個輸出SourceDataLine中，作爲處理這種情況的一種方式。

另一種獲得效率的方法是加載我自己定製的剪輯。我給這個剪輯多個遊標（指針），可以獨立地移動音頻數據。這樣，我可以多次播放剪輯（並以不同的速度）重疊。要使用Java剪輯執行此操作，您必須多次將其加載到RAM中。所以，你可以考慮寫這樣的東西。多個遊標的輸出可以通過SourceDataLine進行求和和播放。