Submitted On 11-APR-2000
Not sure I understand the Evaluation comment above. Are you saying you will be fixing this is v1.3 or a release to follow v1.3? Also, are you saying this same bug existed in v1.2.2? I did NOT see this behavior in JDK 1.2.2, in fact the audio device was released after a clip was stopped (using the Java Plug-in 1.2.2). If you meant that this bug is NOT new in v1.3, I must disagree.
Submitted On 20-APR-2000
I fully agree with the above statement...this IS a new bug
which persists in 1.3rc3!!! it should have a very high
priority for getting this fixed in 1.3 final
Submitted On 08-JUN-2000
I disagree with the evaluation. This appears to me to be a regression, at least on Windows NT 4.0.
I've got an applet that runs in IE with the Java Plug-in. What once worked with JRE 1.2.2 and NT
no longer works with JRE 1.3 and NT.
Interestingly, it works with JRE 1.3 and Windows 2000.
FWIW, this is similar to Bug Id 4190660.
Submitted On 30-OCT-2000
The same issue happens with standard javax.sound.sampled.
But slightly different which is a hint for different experiences with sound:
The first about 4 times of opening and closing the audio device and playing some sounds everthing goes
But after that another test will leave the audío device open!!! After the last bytes have been written to the
SourceDataLine, I do perform a drain on the line to wait until everything is written of course.
But typically to Java in these days, this makes not difference anyway.
Maybe that Applet-AudioClip API uses javax.sound.sampled, which is maybe the reason for that.
This turns the API into complete garbage - especially during development, because I ALWAYS HAVE TO
REBOOT THE SYSTEM after the Audio device is locked.
Cool, this gives me the feeling of writing drivers under Windows, like the good old times.
But shouldn't Java be an improvement of development.
Submitted On 03-JAN-2001
Hey Sun, what's the deal with this regression bug?! It shows
no sign of being corrected in 1.4. What are we supposed to
do, recompile all our 1.2 sound apps with kludges for 1.3
and above? Please look over the comments here and
re-evaluate the impact of this bug. The current behavior is
NOT consistent with that of JDK 1.2.2.
Submitted On 12-JAN-2001
A workaround using J2se_1.3's javax.sound.sampled.* package
to explicitly open/start/close a Clip. It works on NT4.0
SP4 and IE4.0 SP2.
Submitted On 30-MAR-2001
I have a small application (not applet) that plays
AudioClips. I run it on Windows NT 4. It often works fine,
i.e. plays the clip through to the end. However, it
occasionally brings NT down. I have used Exception handlers
liberally to try to find the error. I suspect there is no
Exception being thrown, it's doing something else strange
and evil that causes NT to crash.
Submitted On 21-AUG-2001
A workaround i tried in jdk1.3 that seems to work is to
immediately garbage collect (System.gc()) after calling
audioClip.play(). This _seems_ to release the audio
resources (under NT4 at least) reliably.
Submitted On 13-SEP-2001
I'm running 1.3.1 on WinNT 4 sp 6, and I'm experiencing the
same thing. I can't believe that something as simple as
playing a damn wav file isn't working properly. This needs
to be a priority in the next release!
Submitted On 10-OCT-2001
> A fix now is risky. Postponed to be fixed for Tiger.
I've read that Tiger will be released 2003. Does that mean
that i have to tell my clients: "sorry no sound until 2003.
Sun needs time to fix it" ?
I need this function to inform users that messages arrived.
Without sound its rather useless.
I can't force companies to switch from NT to Win2000.
Submitted On 25-OCT-2001
The Java platform sure has a lot of nice features. It's
too bad that developers consistently get burned when trying
to use those features.
For crying out loud, if I'm responsible for a "serious bug"
(evaluator's words) that's affecting, say, 10% of my
clients, I can't simply say, "Well, it would be risky to
fix it... wait a few years and we'll hopefully have it
fixed then". My ass would be in a sling if I tried that.
But Sun gets away with it because a lot of their clients
don't pay them directly. Could someone with a support
contract with Sun take them to task for their attitude? My
company still doesn't have one.
Also, I'm not convinced, given the evaluation, that the bug
doesn't occur on newer sound cards. I think it's far more
likely that the newer sound cards (and drivers) are simply
more fault tolerant.
P.S. My testing shows that calling System.gc() doesn't fix
the problem. Also, to be clear, AudioClip::stop() doesn't
release the native resources either.
Submitted On 18-NOV-2001
This just cant be true!
It is impossible to play a sound with JDK1.3, without
locking the sound device permanently?
Sun, fix this soon!
Submitted On 29-NOV-2001
The listed workarounds did not work for me, but i've found a
page with an example, about playing sampled audio. And it
Check out the play.java code:
Submitted On 13-DEC-2001
I agree with "alexgru" (see above). I have a JDK 1.3.1_01
application running in NT 4.0. Executing the following code
still held onto the sound driver:
AudioClip sound = Applet.newAudioClip("MySoundFile.au");
sound = null;
But as soon as I added the following line the sound driver
Submitted On 11-JUN-2002
This bug was first posted over 2 and a half years ago! and
is still not fixed! I think Sun should make sure bugs like
this are fixed before spending resources adding even more
stuff into java.
Submitted On 11-JUN-2002
This is a real problem under linux (and probably other OSs),
in particular with applets. Under 1.4.0 an applet will open
the audio device and keep it open until I exit the browser.
Any other sound application will fail while java has the
sound device open.
I find this a very high priority bug, since it is convincing
me of disabling java in my browser alltogether.
Keeping the sound device open for no good reason is just
untolerable. The workarounds above are not an option since I
don't write the applets, I just happen to load them when
visiting some website and keeping the sound device open is a
denial of service.
Please fix this ASAP!
Submitted On 10-JUL-2002
The second most reported (unsolved) bug for the mozilla
project is <a
The mozilla people are looking at totally revamping their
plugin system so that plugin problems are isolated -- but
right now the browser crashes playing Flash animations. Of
which there are millions.
If Sun doesn't get this fixed NOW, I'm afraid the mozilla
developers will storm their corporate HQ and lay siege until
their demands are met. :)
Submitted On 11-SEP-2002
I'm having similar problems on my Linux system using
SDK1.4.0. I can open either the recording line or the
playback line, but not both. Also, closing the recording
line (so the player can be opened) prevents it from being
opened again. Needless to say that the Java sound API is
currently useless for all but the most trivial of audio
Submitted On 18-SEP-2002
I can't understand Why I have to be sufferred by this old bug.
I am developing applications working on Solaris 7. Moreover, I
am using the "SUN's Ultra60 Workstation".
How come this bug haven't been fixed yet?
Sound is critical for all application programs. Unless this bug
is not fixed, I cannot help using other lanuages.
Submitted On 04-MAY-2003
I don't know where the wisecrack
"Win98 and 200 are not affected is that of course the bug
still applies, but is not visible because of the mixing drivers"
comes from, but I'm using build 1.4.1_01-b01 under Win98 SE
and the problem is as demonstratable as ever.
Who classifies this bug as "Closed,fixed", by the way? It looks
to be wide open to me (and everyone around here).
Submitted On 05-MAY-2003
1) it still depends on the audio drivers and the version of
DirectX on your Windows 98 computer. Install a recent
version of DirectX, and recent drivers for your soundcard, and
the problem will very probably not appear anymore.
2) you may want to to learn how to read these bug reports
before making such comments. Above it says: "Release fixed:
Mantis". That means that the fix is available with 1.4.2 and
later. So it was really smart to find out that the bug is "wide
open" in 1.4.1.
Submitted On 17-FEB-2005
Well it's now 2005 and this problem seems to be around still .
Platforms 1.4.2_07 and 1.5.0_01 are afftected.
OS: Windows XP SP 2 with all updates available.
Sound Card: SB Audigy 2 ZS
Thankfully, the fix that Ihannay posted on Dec., 13th 2001 (!) fixed the problem.
I wonder what Sun's quality assurance is doing that took them more than three years to fix this...
PLEASE NOTE: JDK6 is formerly known as Project Mustang