REALLY Simple Sound Loader

Shared Code
#1

I was messing around seeing what I could do with a basic soundloader, and this was the result.



import javax.sound.sampled.AudioInputStream;
import javax.sound.sampled.AudioSystem;
import javax.sound.sampled.Clip;

public class Sound {
	public static Sound exampleSound = loadSound("/soundPath/yoursound.wav");

	private Clip clip;

	public static Sound loadSound(String fileName) {
		Sound sound = new Sound();
		try {
			AudioInputStream ais = AudioSystem.getAudioInputStream(Sound.class
					.getResource(fileName));
			Clip clip = AudioSystem.getClip();
			clip.open(ais);
			sound.clip = clip;
		} catch (Exception e) {
			System.out.println(e);
		}
		return sound;
	}

	public void loop(final int count) {
		try {
			if (clip != null)
				new Thread() {
					public void run() {
						synchronized (clip) {
							clip.stop();
							clip.setFramePosition(0);
							clip.loop(count);
						}
					}
				}.start();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

	public void stop() {
		try {
			if (clip != null) 
				new Thread() {
				 public void run() {
					 synchronized (clip) {
						 clip.stop();
					 }
				 }
			}.start();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

	public void play() {
		try {
			if (clip != null)
				new Thread() {
					public void run() {
						synchronized (clip) {
							clip.stop();
							clip.setFramePosition(0);
							clip.start();
						}
					}
				}.start();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

It’s not brilliant or anything amazing, but I figured I’d share it. :slight_smile:

#2

For the sake of anyone who might want to use this code, I would advise you get rid of those catch blocks and declare the exceptions using throws. You are not doing anything useful with those exceptions, and the end result will be that your users will keep getting NullPointerExceptions after the initial failure. Let the programmers using your code decide how they want to handle the error rather than hiding it from them.

I have no idea why people insist on catching everything. 95% of the time it is the worst thing you can do, and yet the net is full of example showing this. And new coders just blindly follow.

#3

Not a single Exception can be thrown in the 3 last methods anyway. If anything goes wrong, it’s on another (short lived) thread.

#4

“Because Eclipse complains unless I fix it”. So they blindly take the fix without ever bothering to understand why. It doesn’t help that the default fix in every IDE is a crappy one (a better one would have been to convert it to a RuntimeException). IDEs are a double-edged sword, and this sort of thing is Exhibit A for the downside.

#5

Thanks, that’s a really logical explanation for something I was wondering about for a very long time. IDE fixes, of course.

#6

Or even better, just use throws and let it be handled in a more appropriate place, without killing the original stack trace. So much better in so many different ways, and costs less effort. But anyway, this is getting a bit off topic (apologies on my part).

I’m wondering if it will work under OpenJDK on Linux when multiple sounds are played at once? I’ve seen other users from JGO report issues with using Clip in this way.

#7

Don’t use Clip, period! They perform horribly everywhere for doing this sort of thing, though particularly noticeable on Linux, because they open a line to the soundcard for every sound. Simply open a single audio line and mix all sounds to it, or even simpler use a library that already does this - eg. TinySound.

Also, what’s the deal with all those Threads? Sorry, but this code should be mercifully euthanised! :wink:

#8

Actually, yes. Yesterday I tried running 25 sounds at once as a bit of a stress test.
Eventually about 10 of them stopped playing.

I can completely agree with you, this isn’t a great sound system.
Still works for the simplest uses, but if you are using a ton of sounds, music, etc. then you are definitely going to change to a different sound loader.