United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 4302884 Audio device is not released when AudioClip stops
4302884 : Audio device is not released when AudioClip stops

Details
Type:
Bug
Submit Date:
2000-01-06
Status:
Resolved
Updated Date:
2002-11-20
Project Name:
JDK
Resolved Date:
2002-11-20
Component:
client-libs
OS:
solaris_8,solaris_2.6,windows_nt,generic,windows_95
Sub-Component:
javax.sound
CPU:
x86,sparc,generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.2.0,1.3.0,1.3.0_01,1.3.1_01,1.4.0
Fixed Versions:
1.4.2

Related Reports
Duplicate:
JDK-4375591 - Java 2D demo throws MIDI Unavailable exception on NS6 PR3
Duplicate:
JDK-4190660 - playing audio disables sound on NT
Duplicate:
JDK-4480490 - Java plugin never lets go of sound device
Relates:
JDK-4304996 - Aging applet stops receiving events from Java Sound
Relates:
JDK-4811185 - AudioClip doesn't restart Windows sound correctly.
Relates:
JDK-4431740 - Java Sound problem with beep

Sub Tasks

Description

Name: kk38543			Date: 01/05/2000



In JDK versions 1.0.x, 1.1.x, and 1.2.x, the audio
device was handled by AudioClip as follows:

- when AudioClip.play() or AudioClip.loop() was called,  
  the audio device was opened (if not already open) and
  playback of the clip was started.

- when AudioClip.stop() was called, playback of the 
  particular clip was stopped and, if no other clips
  were playing, the audio device was released.

An applet could stop playback of all clips in its
stop() method, so that no sounds could continue playing
once the applet was stopped, and the audio device could
be released.

Currently, in JDK 1.3, the audio device is not released
even if all AudioClips are stopped.  This is a huge problem
because the audio device is frequently an exclusive-use
resource.  An applet running in a browser and using the 
AudioClip interface to play sounds cannot ever close the 
audio device.  The device remains open even if the applet 
stops and the user surfs all over the internet afterwards.
On many audio systems, this means that audio will not be
available to, for instance, ActiveX controls or audio 
plug-in applications in the browser, or to other desktop
applications.  The audio device remains open until the 
browser process exits.


======================================================================

Comments
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis

FIXED IN:
mantis

INTEGRATED IN:
mantis
mantis-b08
2004-06-14 
EVALUATION

kara.kytle@Eng 2000-01-10
The current behaviour is consistent with that of JDK 1.2.2.  Since this is
not a regression from that release, we are committing this serious bug
to the next release.

michael.bundschuh@Eng 2001-05-08
	If possible, try to fix for Merlin Beta 2, otherwise it will
	have to wait until Tiger.

###@###.### 2001-09-14
	All recent soundcards have multithreaded drivers that allow more than one application to access the audio device simultaneously. So Windows 98 and Windows 2000 are probably not affected by this bug. The severity of this bug decreases with time... A fix now is risky. Postponed to be fixed for Tiger.


###@###.### 2001-10-26
	Adressing the issues in the JDC comments:
But there are workarounds, e.g. using javax.sound.sampled.Clip and closing it explicitely. Invoking explicit garbage collection is also a good idea, as the clips are closed on disposal. Be sure to not hold a reference on the AudioClip instance !

Fixing it (which would involve modifying core elements of the Java Sound engine) in a rush (code freeze was already over when the last avaluation comment was made), was considered very risky, in terms of breaking compatibility. I tried very hard to get the fix through, but unfortunately I am not the only one who decides which fixes are still allowed after code freeze.

Please be aware that sound in Java will work, but it will prevent other applications to output sound on specific OS's and specific sound drivers.

In the JDC comments you mix up different issues. This bug is only about the audio device not being closed automatically. Stability issues (i.e. hangs, freeze, crashes) are addressed in Merlin (1.4).

What I meant with "Win98 and 200 are not affected" is that of course the bug still applies, but is not visible because of the mixing drivers (it's not "fault tolerant" - opening and leaving it open is not a fault from the point of view of the driver). The bug symptoms could only be reproduced on Windows 95 and Win NT4 (and I think Win98 first edition).

There are workarounds, e.g. using javax.sound.sampled.Clip and closing it explicitely. Invoking explicit garbage collection is also a good idea, as the clips are closed on disposal. Be sure to not hold a reference on the AudioClip instance ! I have a workaround class which still needs some testing. I will publish this class on the Java Sound homepage. ( http://java.sun.com/products/java-media/sound/ )

I am recommitting to hopper, 1.4.1 - there was no planning for hopper at the time of the last evaluation.


###@###.### 2002-04-23
	Not enough time for Hopper. A bug fix for this bug needs to be tested very thoroughly. Push to Mantis.


###@###.### 2002-10-28
	Fixed by completely remodeling the internal architecture of java.applet.AudioClip. The soundcard is closed automatically after 5 seconds of inactivity. That ensure maximum responsiveness in app(let)s where interactive audio is needed.
2004-06-11 
PUBLIC COMMENTS

Audio device is not released when AudioClip stops
2004-06-10


Hardware and Software, Engineered to Work Together