[ggo-discussion] Re: possible bug on first time installation
- From: Peter Strempel <zotan@xxxxxx>
- To: ggo-discussion@xxxxxxxxxxxxx
- Date: Thu, 16 Jan 2003 16:01:13 +0100
I identified the line where gGo stops. Here is the code snipplet:
private AudioClip clip;
[...]
URL url = SoundHandler.class.getResource(name);
System.err.println("URL = " + url);
if (url == null) {
System.err.println("Soundfile '" + name + "' not found.");
clip = null;
}
else {
try {
System.err.println("Now loading...");
clip = Applet.newAudioClip(url);
System.err.println("Done loading");
} catch (Exception e) {
e.printStackTrace();
} catch (Error e) {
e.printStackTrace();
}
}
System.err.println("SimpleClip " + name + " loaded.");
Now, if I have something running already which blocks /dev/dsp, like any
other Java application with sound (I tried with CGoban2) or Xmms, esd, artsd
etc., then gGo simply hangs at the line with
clip = Applet.newAudioClip(url);
Here is the session output:
voyager:~/development/ggo$ run -keepstderr
loadSounds() entered
SimpleClip /sounds/stone.wav constructor entered.
URL = jar:file:/home/peter/development/ggo/dist/gGo.jar!/sounds/stone.wav
Now loading...
[Hangs here, need to Ctrl-C to abort this]
If I don't run any of the above mentioned applications, things work fine,
everything is loaded and the whole debug output is printed.
As you can see in the code, it does *not* throw any exception or error. It
simply hangs up. Argh! If I had an exception, I could handle it and disable
sound output. According to the API doc, java.applet.Applet.newAudioClip(URL)
does not throw any exception or error. <sigh>
This is the "simple sound" code. The "non-simple sound" code works very
different, it doesn't use java.applet.AudioClip at all. It is an own Thread
which uses a ByteArrayOutputStream to write to the sound device, and then
frees the device again. Basically much better, but it occasionally crashes
and does not work well on Windows.
But on Linux the non-simple sound starts properly even if
xmms/esd/artsd/etc. is already running.
Anyways, I currently have no idea how to find out if gGo blocks on that
mentioned line, as neither Exception nor Error are thrown. If any Java geek
reading this has an idea, please share it with me. :)
Note: On Windoze all of the above works, you can run WinAmp or whatever and
then start gGo with "simple sound". The whole problem with locking the sound
device does not occur on Windows (hate to say it).
Peter
Other related posts:
