The sounds are played when 5 of the same monster in my game fires out a projectile. The sound sounds very distorted because all the monster are firing the projectile at the same time which would mean each sound played from each projectile is being played simultaneously. This also seems to eat up the RAM on my computer.

I also have a game background music being played too.

How do I fix the issue? I am surprise only 5 monsters can produce a sound issue. How come Galaga, the arcade shooter game does not have this problem?

Because it doesn't play 5 of the same sound at the same time.

How are you loading, storing and playing your sounds?

Like this:

 
public void playFireSound() {
// TODO Auto-generated method stub
try
{
/* get a clip from the AudioSystem Class
* the clip plays back an audio file or audio stream
*/
Clip clip = AudioSystem.getClip();
/*
* ask the clip to open an audio input stream with the provided file 
*/
/*
* provide the file with a String directory
*/
clip.open(AudioSystem.getAudioInputStream(new File("src/Sounds/fire.wav")));
/*
* start the clip
*/
clip.start();
}
catch(Exception e)
{
e.printStackTrace(System.out);
}
}

You should not be loading the sound file as soon as it's needed - that causes a lot of slow-down since it needs to be read from the disk. All resources should be loaded beforehand and thus stored in the RAM for quick access. When you need to play a sound effect, you will reference the sound that is stored in the RAM.

You should not be loading the sound file as soon as it's needed - that causes a lot of slow-down since it needs to be read from the disk. All resources should be loaded beforehand and thus stored in the RAM for quick access. When you need to play a sound effect, you will reference the sound that is stored in the RAM.

Interesting! What do you mean by read from disk? Where is this disk located? How do I store it in RAM? You mean like store these sound files in an arrayList of of Clips?

clip.open(AudioSystem.getAudioInputStream(new File("src/Sounds/fire.wav")));

By disk, I mean hard drive (though, if this game were on an optical disk, it would be reading it off of the game disk itself). This command is telling your computer to read from the hard drive at the location you specified. This is a comparatively slow process as it involves moving physical, mechanical parts in the hard drive device. This is not something you want to do in the middle of game play, and especially not every time the "playFireSound()" function is called. You'll want to load your sound files into the RAM at the start-up of your program (or if your game has loading screens, you would do it then as needed). Yes, the sound files should be stored in a dynamic array. Currently, you're creating a clip every time "playFireSound()" is called. The clips should be created beforehand and should remain in the memory as needed. It's only the play function that should be called when a sound effect needs to be played.

If the sounds are completely in sync, then the issue has to do with clipping - identical sample values get added, causing the waveform to become too loud for playback so it gets truncated (clipped), which sounds like distortion (in fact, this is how guitar distortion works - in very broad terms).

If the sounds are being played almost in sync, but not completely, then you're getting what is known as comb filtering, which generally sounds even "worse" than outright clipping. Comb filtering is used in music and sound production to achieve certain effects, but generally it's considered undesirable.

The problem is you can't just adjust the volume of your triggered samples as that'll mess up any balance (and positioning) you might have. Also, that wouldn't take care of comb filtering. The solution, therefore, is to store your sound files at something like half volume, so you can do some layering and limit synchronous sounds to something like two instances. You'll also need to add a "minimum delay" that the game waits before triggering the same sound more than twice. The worst comb filtering happens with delays of 10ms or less so something like a 100 or 50 ms delay would be a good place to start experimenting.

clip.open(AudioSystem.getAudioInputStream(new File("src/Sounds/fire.wav")));

By disk, I mean hard drive (though, if this game were on an optical disk, it would be reading it off of the game disk itself). This command is telling your computer to read from the hard drive at the location you specified. This is a comparatively slow process as it involves moving physical, mechanical parts in the hard drive device. This is not something you want to do in the middle of game play, and especially not every time the "playFireSound()" function is called. You'll want to load your sound files into the RAM at the start-up of your program (or if your game has loading screens, you would do it then as needed). Yes, the sound files should be stored in a dynamic array. Currently, you're creating a clip every time "playFireSound()" is called. The clips should be created beforehand and should remain in the memory as needed. It's only the play function that should be called when a sound effect needs to be played.

Oh! I see now! So that is why! Thanks for the awesome knowledge.

If the sounds are completely in sync, then the issue has to do with clipping - identical sample values get added, causing the waveform to become too loud for playback so it gets truncated (clipped), which sounds like distortion (in fact, this is how guitar distortion works - in very broad terms).

If the sounds are being played almost in sync, but not completely, then you're getting what is known as comb filtering, which generally sounds even "worse" than outright clipping. Comb filtering is used in music and sound production to achieve certain effects, but generally it's considered undesirable.

The problem is you can't just adjust the volume of your triggered samples as that'll mess up any balance (and positioning) you might have. Also, that wouldn't take care of comb filtering. The solution, therefore, is to store your sound files at something like half volume, so you can do some layering and limit synchronous sounds to something like two instances. You'll also need to add a "minimum delay" that the game waits before triggering the same sound more than twice. The worst comb filtering happens with delays of 10ms or less so something like a 100 or 50 ms delay would be a good place to start experimenting.

Interesting. I will bear in mind about this and experiment.