Can't figure out how to do Java Audio properly.

Newbie & Debugging Questions
#41

A simple case example might help. This isn’t a common problem, or at least, it isn’t one I’ve come across before, or heard anyone mention before. Usually if there is a problem that arises in the transition from IDE to jar, it involves the way in which the resources are addressed. But that shouldn’t be what is happening in your case since you are able to hear the start of your sounds.

I’ve found working with sound has tried my patience to the extreme. I don’t know that there are many game players that really understand it very well, or even many Java programmers. Most of us are just happy to get something to work.

One exception to this is nsigma. He really knows his stuff, and I recommend paying extra attention to any advice he posts.

#42

Is there a way I could convert it from its current functionality to maybe use a Line Listener like was suggested earlier? I’m not sure if that would correct the problem, but it’s worth a try. My code as it is now is:


public void play(final double gain, final boolean smoothLoop) {
    final Clip clip = createClip();
    FloatControl gainControl = (FloatControl)clip.getControl(FloatControl.Type.MASTER_GAIN);
    float dB = (float)(Math.log(gain) / Math.log(10.0) * 20.0);
    gainControl.setValue(dB);
    new Thread(new Runnable() {
        @Override
        public void run() {
            active = true;
            if(!smoothLoop) clip.start();
            else clip.loop(Clip.LOOP_CONTINUOUSLY);
            while(active) {
                if(!clip.isRunning() && !smoothLoop) active = false;
            }
            if(smoothLoop) clip.stop();
        }
    }).start();
}
#43

Here’a an example of the basic form for adding a LineListener, and testing for an event:


		clip.addLineListener(new LineListener()
		{
			@Override
			public void update(LineEvent arg0)
			{
				if (arg0.getType() == LineEvent.Type.STOP)
				{  
					// do something}
				}
			}
		});

But that begs the question of how a looping clip gets a signal to stop in the first place.

If we are talking about a machine gun with a fixed duration, e.g. short bursts, something like this is fine. (No LineListener needed. No while loop needed.)


	clip.start();  // assume looping, volume, etc. has already been set up.
	Thread.sleep(machineGunDuration);
	clip.stop();  // then maybe reset it to the starting frame so you can reuse it

Sometimes I break the Thread.sleep() into smaller increments and check a state variable before continuing to the next sleep, to make the duration more granular. The state variable should be volatile, of course, and will only be as accurate as the limited real time guarantees of the JVM/OS.


	clip.start();
	for (int i = 0; i = 10; i++)
	{
		Thread.sleep(oneTenthMachineGunDuration);
		if (stopClip) break;
	}
	clip.stop();

Am just free-typing this. So, hopefully I didn’t facepalm anything.

Even the 2nd example above uses vastly less cpu than leaving the thread spinning. I’ve only seen spinning threads in “spin locks” where the anticipated duration was very short.

Couple of suggestions/observations which may help in other regards:

  • It is kind of unusual to make a new Clip and play it with every play. Usually one restarts a given clip. If you are doing a single playback, a SourceDataLine starts quicker, so as not to incur the repeated i/o loading. Maybe you are doing this as a quick/dirty way to allow concurrent sounds?

  • Not every OS will support MASTER_GAIN, just a heads up.

  • Not every OS will support multiple outputs (for sure some Linux won’t), hence the recommendation for TinySound which mixes all sounds into a single output line. Of course, to get TinySound, we are back at the annoying task of figuring out how to use GitHub. But since Git is such a common tool for sharing code, the “side trip” is worth it, imho.

#44

Ok, can I just ask how the idea got started that I was talking about the machine gun? The machine gun is not looped, and the sound is played every time the gun is fired… the flamethrower is what’s looped. That being said, it doesn’t seem like anyone has a solution for this, so I’m gonna try my hand at TinySound.

#45

I once used a loop for a machine gun sound effect built from individual gunshots. From that I made a mental error.

Substitute the words flamethrower for machine gun. The above should still work.

#46

That’s the problem, though. What you posted is exactly what I was doing originally that caused the overlapping sounds to freeze the game.

#47

Mmmm. I’m having trouble keeping track. The overlapping sounds are freezing the game? That makes me wonder about deadlocks. Your early code had a lot of synchronization. Are you still employing that? Infinite loops also come to mind as a plausible cause.

An earlier post said that the sounds would play but only half-way (“cut short”), and I didn’t see mention of the game freezing with that post. So I assumed that the game continued and only the sounds were acting weird. I have no idea what would cause that, except maybe attempting to use a given clip concurrently (where the second play causes the cut-off).

I had another thought about managing the flamethrower, if you are still entertaining various strategies for handling that. I am working from the assumption that the sound is a looping clip. The “problem” then is how to have the event which stops the flamethrower find this clip in order to issue a clip.stop(). Yes? I’m going to assume that there may be more than one flamethrower operating at a given time, but that we can identify the operator of the flamethrower when we start or stop it.

One thing I started doing is to create a single class called GameSound, and have it handle all the sound f/x. Within that class, I’d have a public method like .flameThrower(operator, flaming). Then have this method do the following:

if flaming is true, get an instance of the clip (from a preallocated pool), store it with the operator in a hash table, and start the clip.

if flaming is false, use the operator to locate the clip in the hash table, and stop the clip, resetting it to starting position and returning it to the pool.

I’ve been using the pooling idea for a ‘SoundField’ tool (used to randomly play a selection of sounds, with overlapping of same sounds supported) and also for various synths that are polyphonic (creating a pool of “notes”), and it has worked without needing synchronization to manage the pool. It took a little head-scratching to keep it concurrency safe, but it was doable.

What is kind of vexing for many is that these sorts of things aren’t available directly from Java or from most game libraries even though they seem like they should be common. Java sound gets pretty low level, and the high level capabilities they do provide are a take-em-or-leave-em proposition.

#48

Phil, please read earlier in the thread. I already said I corrected the freezing issue… the sounds being cut short is unrelated. And just a few posts up is the code I’m currently using.

#49

Alright, so I switched over to TinySound and got it working for the weapons. But there’s one remaining problem. I went with the Music object, rather than Sound, so I could make the Flamethrower work (needed to be able to loop it and only play it if it’s not already playing). The problem being that now the zombie moans are doing exactly what I originally set out to fix, being that I need them to overlap, and the Music object seems to restart the sound whenever the play() is called, which I understand… but how can I support playing the same sound over itself like I was doing with the AudioData class I made?

EDIT: Nevermind. I just decided to go with loading the sound every time it’s played if it’s designated as an overlapping sound (really only used for the moans) and playing that instead. Otherwise, it just uses the sound it loaded at the start. I realize this may not be very efficient, but I’m going to be making it so zombies only moan once after they’re spawned so it doesn’t cause too much of a burden.

Why is sound so troublesome in Java?

#50

I think sound is troublesome in every language… just other languages hide it better.