occassionally, playing audio on NT
disables the sound.  that is,
no other device can get to the sound
device.  the only way to fix
this is to remote. 
This is a real pain.
Here's a sample program.



import java.applet.*;
import java.net.*;
public class LoadAudioApp {
    public static void main(String[] args) {
        try {
            URL url = new URL(null, "file:///d:/touchdown.au");
            AudioClip ac = Applet.newAudioClip(url);
            ac.play();
        } catch (MalformedURLException e) {
           e.printStackTrace();
        }
    }
}
(Review ID: 42759)
======================================================================

N/A

N/A

more detail: if you quit the appletviewer
while the applet is playing a sound, the
sound device is not properly closed.
any app (java or not) can no longer play
sounds.  Only a reboot fixes it.

The program above doesn't cause any problems on my 
system (NT4.0/SP4 with Creative PCI64 sound card).
It doesn't work (= play a sound) either, because 
the application would have to wait for the sound 
to be played before it terminates.
However, I experienced a problem which seems to 
be related with the reported bug: 
After playing a sound in a Java application (with 
AudioClip.play()) the wave output device is blocked 
for all other applications until the VM terminates. 
Workaround: Call AudioClip.stop() after the clip 
has been played. At least on my system, this causes 
the sound device to be released. 
This behaviour definitely is a bug - according to 
the documetation, stop() shouldn't do anything else 
than to stop this AudioClip if it is currently 
playing.
Maybe calling stop() on any AudioClip before exiting 
could also help with the reported problem ?!

I have the same problem on my SUN Solaris and one of my Win95 machines.

I followed phoedl's advice and called AudioClip.stop().
It worked! My audio device was released. I am running
NT4.0 and using JDK1.2.  I had to play the sound clips
in separate threads:
public class SoundPlayer extends Thread {
   // this class plays sound clips
   // Have to implement this class as a thread because the AudioClip
   // is not releasing the sound device (bug #4190660).  I am playing
   // sounds in separate threads, and explicitly call the
   // AudioClip.stop() method after 6 seconds to force the release of
   // the audio device
   private URL clip;
   public SoundPlayer (URL clip) {
	this.clip = clip;
	this.start();
   }
   public synchronized void Sleep (AudioClip audio) {
	try {
	   this.wait(6000); // put thread to sleep
	} catch (IllegalMonitorStateException e) {
	   System.out.println("Illegal Monitor");
	} catch (InterruptedException e) {
  	} finally {
	   audio.stop(); // release the audio device
	}
   }
   public void run () {
	AudioClip audioClip = Applet.newAudioClip(clip);
	audioClip.play(); // play the sound clip
	Sleep(audioClip);
   }
}
I estimated that none of my sound clips lasts more
than 6 seconds, therefore I asked the thread to
sleep for 6 seconds and than call stop(). Calling
stop() just right after play() (without sleeping)
will result in sounds not being played at all.  
You can further customize this class by passing
in the estimated playing time of the audio clip
to the constructor, so that each SoundPlayer 
thread will sleep for a time specific to that
sound clip. 

Any runtime way of telling how long an AudioClip is???

AudioClip.play() in a Java 1.2.1 application 
on my NT 4.0 machine hangs the entire system.
(It actually intermittently worked for a while
but now always hangs). Card is Soundblaster 16
(a CT2800 variant, Vibra 16S chip). All other
audio works OK. Will see if later Service Packs
fix, and then will try the stop() workaround.
However it looks like sound on NT 4.0 needs some 
serious attention

We get the same problem on our system, however it
takes hours before the sound stops.  If I exit the
VM, and restart our app it works fine.  I am about
to try the AudioClip.stop() solution.  Hope it
works, otherwise the sound will have to be done
with JNI calling Windows (yuk!) functions.  Kinda
makes the code non-portable!

The AudioClip.stop() solution worked for me with the Java Plug-in and Internet Explorer until I upgraded to 
Java 1.3 on NT.  Now, the problem is back again.  On the bright side, I don't see the behavior on Windows 
2000 and Java 1.3, or on Windows 98 and Java 1.2.2.  But I don't know if the workaround is fixing the 
problem, or if the problem itself is gone.

Using the AudioClip class in a stand alone game application 
with lots of simmultaneous and looped sounds, our sound 
device was frequently (not always) left unreleased when the 
app exited.  This is a game, with lots of threads and 
simultaneous and looped sounds, so calling stop on every 
sound on exit from a game would have required an elaborate 
registration system.  Our work around, which seems 
completely effective in 1.3 on NT (haven't got to the 
testing stage with 1.2 or other systems), is as follows:
 - add a finalization to the wrapper holding the AudioClip 
which calls AudioClip.stop()
 - use the deprecated System.runFinalizersOnExit(true) to 
ensure finalizers are already called
 - debug AWT-based classes to fix the deadlock which is the 
reason why runFinalizersOnExit() is deprecated! (Couldn't 
call Container removeAll() method, had to do the removes on 
by one.)

I'll try to remember to update this when we've gotten 
through testing on 1.2 and other OS's next month.

Found same problem using JMF. Just by calling Applet.getSoundClip(), audio resource was hogged.
JMF would not play sound. After commenting out the Applet.getSoundClip() code, JMF works fine.
I encountered this on NT4.0, JDK1.3, and JMF2.1(Windows PerformancePack).

My workaround-
If you're using JMF2.1, it comes with JavaSound so ditch the Applet!
Rock on

The audioclip.stop() solution did not work for me when using
webstart or plugin (1.3.1) on NT

I'm trying a small application very much like the example 
given. It works on Win 2000, but only sporadically on NT 
(will play the sound only sometimes, but mainly not - there 
doesn't seem to be any logic as to when it works or not)