JDK-4732218 : Clip.drain does not actually block until all I/O is complete as documented.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 1.4.1
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-08-15
  • Updated: 2002-11-20
  • Resolved: 2002-11-20
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
1.4.2 mantisFixed
Description

Name: jl125535			Date: 08/15/2002


FULL PRODUCT VERSION :
Failures under both of these:

Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)


FULL OPERATING SYSTEM VERSION :

glibc-2.2.4-19.3

Linux Redhat 7.2
Linux 2.4.9-13 #1 Tue Oct 30 20:11:04 EST 2001 i686 unknown


EXTRA RELEVANT SYSTEM CONFIGURATION :
sblive, no ALSA

A DESCRIPTION OF THE PROBLEM :
The method: Clip.drain does not actually block until all I/O
is complete as documented at http://java.sun.com/j2se/1.4/docs/api/javax/sound/sampled/DataLine.html#drain().  It would seem that the "internal buffer" of a clip is the entire clip.

'drain' should block until all queued audio has finished
playing.  Instead, it seems to return immediately.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Create an audio clip to play an audio file
2. start the clip playing
3.Call 'drain' to wait for the clip to finish
4. Call 'close' to close the clip



EXPECTED VERSUS ACTUAL BEHAVIOR :
I would expect the call to 'drain' to block until the clip
finishes playing.

Instead, the 'drain' call returns immediately with the
result being that the clip is closed pre-maturely.



ERROR MESSAGES/STACK TRACES THAT OCCUR :
None:



REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------

import javax.sound.sampled.*;

public class AudioDrainDemo {
    private Clip clip;
    private int count = 1;
    private boolean useLineListener = false;

    
    public void playClip() throws Exception {

// testLong.wav is a 10 second long wave file

        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.open(audioInputStream);
        System.out.println(" ---------- start " + count + " --------");
        clip.start();

        System.out.println("waiting ... ");
        clip.drain();
        clip.close();
        System.out.println("... done");
        count++;
    }

    public static void main(String[] args) throws Exception {
        AudioDrainDemo aird = new AudioDrainDemo();

        for (int i = 0; i < 1000; i++) {
            System.out.println("FreeMem: " + Runtime.getRuntime().freeMemory() +
                    " TotMem: " + Runtime.getRuntime().totalMemory());
            aird.playClip();
        }
        System.exit(0);
    }
}

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

CUSTOMER WORKAROUND :
You can use a LineListener to catch the STOP LineEvent, but
the STOP event has been unreliable as well.
(Review ID: 160273) 
======================================================================

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis mantis-b08
14-06-2004

EVALUATION ###@###.### 2002-08-19 Florian Bomers will evaluate more fully when he returns from vacation. However, this is not a hopper stopper. ###@###.### 2002-09-04 Direct audio drivers should fix this problem, so committing it to mantis.
04-09-2002