gerry99
asked on
How to avoid "no audio device" applet death
I have an applet that can play a sound in response to an external event.
My code is:
AudioClip clip = applet.getAudioClip( applet.getCodeBase(), "Ding.au" );
clip.play();
If 2 instance of the applet are running or some other program, such as my mail program, plays a sound, and the timing of these events causes the clips to interfere with each other, the applet writes an error message to the Java console:
"no audio device"
After this message has appeared the next, and every subsequent, clip.play() will block forever. The applet is hung.
This is totally un-acceptable, however I cannot find any way to determine that this has happened, nor is their any excpetion I could catch to allow my applet to recover?
Does anyone have a workaround? Is there an open bug on the sun Java Developer Connection website that I can vote for?
Thanks,
Gerry
My code is:
AudioClip clip = applet.getAudioClip( applet.getCodeBase(), "Ding.au" );
clip.play();
If 2 instance of the applet are running or some other program, such as my mail program, plays a sound, and the timing of these events causes the clips to interfere with each other, the applet writes an error message to the Java console:
"no audio device"
After this message has appeared the next, and every subsequent, clip.play() will block forever. The applet is hung.
This is totally un-acceptable, however I cannot find any way to determine that this has happened, nor is their any excpetion I could catch to allow my applet to recover?
Does anyone have a workaround? Is there an open bug on the sun Java Developer Connection website that I can vote for?
Thanks,
Gerry
ASKER
heyhey,
This is my code, get a sound, then play it:
AudioClip clip = applet.getAudioClip( applet.getCodeBase(), "Ding.au" );
clip.play();
To reproduce the bug, put the play call in a loop with a Thread.sleep() of 5 seconds between each time it plays the sound. Then run 2 or more instances of this applet. FYI, "ding" is the windows ding sound saved in AU format.
Thanks,
Gerry
This is my code, get a sound, then play it:
AudioClip clip = applet.getAudioClip( applet.getCodeBase(), "Ding.au" );
clip.play();
To reproduce the bug, put the play call in a loop with a Thread.sleep() of 5 seconds between each time it plays the sound. Then run 2 or more instances of this applet. FYI, "ding" is the windows ding sound saved in AU format.
Thanks,
Gerry
all you can do is to implement the Singleton pattern - put all your audio related code in one object that is accessible from all applets
public class AudioManager
{
ptivate static AudioManager default = new AudioManager ();
public static AudioManager getDefault()
{
return default;
}
private AudioClip currentClip;
public void play(Applet applet, String soundFile)
{
if (currentClip != null)
{
currentClip.stop();
currentClip = null;
}
if (url != null)
{
currentClip = applet.getAudioClip(applet
clip.play();
}
}
}
use it
AudioClip.getDefault().pla
public class AudioManager
{
ptivate static AudioManager default = new AudioManager ();
public static AudioManager getDefault()
{
return default;
}
private AudioClip currentClip;
public void play(Applet applet, String soundFile)
{
if (currentClip != null)
{
currentClip.stop();
currentClip = null;
}
if (url != null)
{
currentClip = applet.getAudioClip(applet
clip.play();
}
}
}
use it
AudioClip.getDefault().pla
The AudioClip.play() method hogs the audio device as I discovered. Try running your applet and something else that produces sound...like winamp or something, you will find that it will tell you that it can't play music because the sound device is not available.
yes - that's what my workaround is for ... :)
ASKER
heyhey,
Since I posted my question I implemented a workaround that has a simular effect to your suggestion of using a singleton AudioManager. I created a thread to play audio clips, primarily so that if another program wants to use the audio device and if this causes the AudioClip.play() method to hang, it will only hang my audio playing thread, not my worker thread that I was counting on having perform some useful task. Your singleton pattern will still hang my worker thread if I use it.
Your suggestions are useful however, I'd like to know if there is a way to detect the "no audio device" error and to somehow reset the part of the VM that plays music or at least be able to avoid making the AudioClip.play() call. (If you can't detect the error making this call will block your thread forever.)
Thanks
Since I posted my question I implemented a workaround that has a simular effect to your suggestion of using a singleton AudioManager. I created a thread to play audio clips, primarily so that if another program wants to use the audio device and if this causes the AudioClip.play() method to hang, it will only hang my audio playing thread, not my worker thread that I was counting on having perform some useful task. Your singleton pattern will still hang my worker thread if I use it.
Your suggestions are useful however, I'd like to know if there is a way to detect the "no audio device" error and to somehow reset the part of the VM that plays music or at least be able to avoid making the AudioClip.play() call. (If you can't detect the error making this call will block your thread forever.)
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for the help. My question was really un-answerable, because there is no application level way to work around a bug in the Windows-x VM AudioClip implementation. As far as I can tell the only safe thing is to let you Audio playing thread hang, and get the rest of your applet out of the way.
I suppose that you can implement some workaround ... (not sure)
can you post some sample code ?