JDK-4318062 : MixerSourceLine.drain hangs after repeated use
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.5.1
  • CPU: sparc
  • Submitted: 2000-03-02
  • Updated: 2002-09-04
  • Resolved: 2002-09-04
Related Reports
Duplicate :  
JDK-4392953 - SourceDataLine.drain() hangs in threaded use
Relates :  
JDK-4428704 - RAS: Sound Reliability Tests Consistently Crash In Less Than Five Hours.
Description
This can be reproduced consistently on WinNT under the following scenario:

- A GUI application is used.  It has a button to playback a short
  audio clip each time it's pressed.
- When the button is pressed, it creates a SourceDataLine to play back
  a short clip of PCM data.
- At the end of the short clip, SourceDataLine.drain is called.  When
  that returns, the SourceDataLine is closed.
- By repeatedly hitting the button after a while, the CPU will reach
  100% and stay at 100% indefinitely.

By doing a thread dump at this point, there will a few threads
that got stuck in the com.sun.media.sound.MixerSourceLine.drain call.
Comments
EVALUATION michael.bundschuh@Eng 2000-03-09 This is a high priority bug for JMF, as well as J2SE, we should get the fix in ASAP, as it is affecting real customers like APUNIX. ----- Test case, DrainTest.java, is attached. This problem has nothing to do with drain(); it is quite normal that some threads are found to be in this method when the threads are dumped because it is a blocking call that takes some time to complete. Instead, the bug occurs when multiple SourceDataLines are underflowing; JMF causes this condition when it is draining multiple lines. When all data from a line has been played, the high-priority audio engine thread makes aggressive efforts to read data from the underflowing line. When several lines are in this state, the CPU can become overloaded. The audio thread is the highest priority thread, so other threads are able to run (such as those which should be returning from a call to drain()). I fixed this bug on Solaris by changing HAE_API_SolarisOS.c to make sure the audio thread always sleeps at least once between cycles of the engine. I also changed the mechanism of the drain() method to monitor the "active" state of the line rather than block in native code. I don't see the problem occurring on WinNT. However, I made the analogous change in HAE_API_WinOS.c because it should be possible for the problem to occur, and because I'd like to keep the code consistent when possible. kara.kytle@Eng 2000-03-22 ###@###.### 2002-04-23 Need to find out if this fix made it into the release.
22-03-2000