United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4434125 LineEvent.Type.STOP is returned too early for short sound clips
JDK-4434125 : LineEvent.Type.STOP is returned too early for short sound clips

Details
Type:
Bug
Submit Date:
2001-04-04
Status:
Resolved
Updated Date:
2003-10-24
Project Name:
JDK
Resolved Date:
2003-10-24
Component:
client-libs
OS:
windows_nt,linux
Sub-Component:
javax.sound
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.4.0,1.4.1
Fixed Versions:
5.0 (b26)

Related Reports

Sub Tasks

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
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
                                     
2003-10-16
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger
tiger-beta

FIXED IN:
tiger-beta

INTEGRATED IN:
tiger-b26
tiger-beta


                                     
2004-06-14



Hardware and Software, Engineered to Work Together