JDK-4434125 : LineEvent.Type.STOP is returned too early for short sound clips
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 1.4.0,1.4.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows_nt
  • CPU: x86
  • Submitted: 2001-04-04
  • Updated: 2003-10-24
  • Resolved: 2003-10-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b26Fixed
Description
Copy the attached java program and sound clip into the same directory and compile and run the program. It should play a short sound clip. Unfortunately, nothing is played. Substituting a longer clip for the current one causes the program to play that clip fine.

The problem is that for short sound clips, EOM is generated too early, thus causing a LineEvent.Type.STOP event before the sound is even played. This code, which tries to close the Clip when it receives a STOP, thus closes the clip too early. Commenting out line 43, the close() call, fixes the problem but causes other problems in our code since it leaves the Clip open.

This occurs on Windows but not on Solaris.

Name: jl125535			Date: 08/15/2002


The problem also occurs in Linux.

FULL PRODUCT VERSION :
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)


FULL OPERATING SYSTEM VERSION :
Linux  2.4.9-13 #1 Tue Oct 30 20:11:04 EST 2001 i686 unknown
glibc-2.2.4-19.3


EXTRA RELEVANT SYSTEM CONFIGURATION :
sblive no AlSA

A DESCRIPTION OF THE PROBLEM :
The LineEvent.Type.STOP seems to arrive a few tenths of a second too soon.  There is still sound remaining to be played when it arrives.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Setup a LineListener on a clip
2.Play the clip
3.Use the LineEvent.Type.STOP event to trigger closing of the clip

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected results:

The clip to play until completion and then closed


Actual Results:

The clip stops playing before the end.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import javax.sound.sampled.*;

public class EarlyStopDemo {
    private Clip clip;
    
    public void go() throws Exception {
        AudioInputStream audioInputStream =
            AudioSystem.getAudioInputStream(
                new java.io.File("testLong.wav"));
        DataLine.Info info =
                new DataLine.Info(Clip.class, audioInputStream.getFormat());
        clip = (Clip) AudioSystem.getLine(info);
        clip.addLineListener(new LineListener() {
                public void update(LineEvent e) {
                    if (e.getType() == LineEvent.Type.STOP) {
                        synchronized(clip) {
                            clip.notify();
                        }
                    }
                }
            });
        clip.open(audioInputStream);
        clip.start();
        synchronized (clip) {
            clip.wait();
        }
        clip.close();
    }

    public static void main(String[] args) throws Exception {
        EarlyStopDemo acd = new EarlyStopDemo();
        for (int i = 0; i < 10 ; i++ ) {
            acd.go();
        }
    }
}


---------- END SOURCE ----------

CUSTOMER WORKAROUND :
Put a delay between when the STOP event is received and when
the clip is closed.
(Review ID: 160282)
======================================================================

###@###.### 2003-08-18
Both of these tests return the following error on Solaris 8 JDK 1.5.0-beta-b10

No line matching interface Clip supporting format PCM_SIGNED, 16000.0 Hz, 16 bit, mono, little-endian, audio data is supported. 

Could not reproduce behavior as a result.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b26 tiger-beta
14-06-2004

EVALUATION ###@###.### 2002-05-30 Not sure if this is still happening. Committing to Mantis. ###@###.### 2002-05-31 This is still broken in 1.4.1-beta-b13. ###@###.### 2002-10-30 Since Tiger will have direct audio renderers, this bug should be fixed with them and I recommit to Tiger. There are no engineering resources to fix this in the Java Sound Engine in the Mantis time frame. For linux, when using the new ALSA mixer (with 1.4.2), the problem should not occur. Verified to work fine with DirectAudioDevices. The old implementation (Java Sound Engine) will not be fixed. To make it clear: the fix will work with 1.5.0 or later, on - Solaris with Mixer enabled - Windows with Direct Sound 5 or later - Linux with ALSA and hardware or software mixing enabled in ALSA Note, too, that the test program waits the clip object itself. The old Java Sound implementation uses that notification internally, too. That may be a reason why the wait() returns too early. Also note the remote possibility of spurious wakeups in wait(). To exclude side effects, programs should never wait on objects returned by Java Sound (the new DirectAudioDevices have a private lock though). ###@###.### 2003-10-16
16-10-2003