Home/ Questions/Q 8223209
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T14:36:27+00:00

I’ve read here on StackOverflow that every time you play a clip in JavaSound,

  • 0

I’ve read here on StackOverflow that every time you play a clip in JavaSound, behind the scenes it creates a thread to play it. If it is true (and if it isn’t please tell me, as I have not found any documentation/source on that), would it be considered as an expensive call, since creating threads is an expensive task in any OS/JVM? I am not sure yet, but I may need to play 10 to 20 clips concurrently, so I was wondering if that would be a problem.

PS: If it is an exoensive call for other reasons beside creating threads, please let me know.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Threads are NOT expensive, particularly. I’ve personally made a program that has over 500 running. Server programs can spawn considerably more than that.

    Sound processing is not inexpensive, but I don’t know that it is much more cpu-intensive than many graphics effects, like lighting in 3D. I made a program that both played a sound and made a “glow ball” that grew and faded while the sound was playing. The “glow ball” continually updated a RadialGradientPaint to achieve this effect. I ran into a ceiling of about 10 balls and sounds, and it was the graphical balls that were the bigger processing load.

    Still, you might not be able to do a whole lot else with 17 Clips playing. You’ll have to test it, and will hear dropouts if the cpu can’t keep up.

    Your 17 Clips may take up a huge amount of RAM. You know that they are all loaded into memory, yes? At 44100 samples for each second, and typically 4 bytes per sample (stereo, 16-bit PCM), that starts to add up quick.

    So, there may be reasons to consider using SourceDataLine’s instead, especially for the longer sounds.

    Also, it seems some OS systems don’t handle multiple sounds very well. I’ve had problems come up here with Linux in particular. I ended up writing a program to mix all the playing sounds into one output SourceDataLine as a way to handle this.

    Another way I get some efficiency is that I load my own custom made Clip. I’ve giving this Clip multiple cursors (pointers) that can independently move through the audio data. This way, I can play a Clip multiple times (and at varying speeds) overlapping. To do this with a Java Clip, you have to load it into RAM multiple times. So, you might consider writing something like that. The output from the multiple cursors can be summed and played via a SourceDataLine.

    • 0