JDK-5070081 : REGRESSION: javax.sound.sampled.Clip loses position when stopped
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 5.0
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-06-30
  • Updated: 2005-08-17
  • Resolved: 2005-08-17
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 JDK 6
5.0u5Fixed 6 b48Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
Name: jl125535			Date: 06/30/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta3-b57)
Java HotSpot(TM) Client VM (build 1.5.0-beta3-b57, mixed mode)

REGRESSION : Last worked with 
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Creative SoundBlaster Live!

A DESCRIPTION OF THE PROBLEM :
If you call "stop()" on a Clip that is playing, the position of the Clip jumps.
The subsequent starting position is arbirtary.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start playing a Clip and then stop it using "stop()" before it ends.
Call "start()" to resume playback.

Run the example code supplied and use jre1.5 and see the results.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expected to hear the sound of "1 2 3 4"
and a printout similar to:
Clip length: 60912
Position before stop: 21594
Position after stop: 21595
Position at end: 60912
ACTUAL -
I heard the sound "1 4 4" (may vary)
and the following result was printed:
Clip length: 60912
Position before stop: 22083
Position after stop: 44541
Position at end: 77724


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.net.URL;
import javax.sound.sampled.AudioFormat;
import javax.sound.sampled.AudioInputStream;
import javax.sound.sampled.AudioSystem;
import javax.sound.sampled.Clip;
import javax.sound.sampled.DataLine;

public class BugTest {
  public static void main(String[] args) throws Exception {
    // create a clip from a file
    AudioInputStream audioInputStream = AudioSystem.getAudioInputStream(new //URL("http://www.speech.kth.se/~mikaeln/1234.wav"));
java.io.File("1234.wav"));
    AudioFormat audioFormat = audioInputStream.getFormat();
    DataLine.Info info = new DataLine.Info(Clip.class, audioFormat);
    Clip clip = (Clip)AudioSystem.getLine(info);
    clip.open(audioInputStream);
    audioInputStream.close();
    System.out.println("Clip length: " + clip.getFrameLength());
    clip.start();			// start playing
    Thread.sleep(1000);			// wait a sec
    int pos = clip.getFramePosition();	// store the position
    System.out.println("Position before stop: " + pos);
    clip.stop();			// and then stop
//    clip.setFramePosition(pos);		// set the position
    System.out.println("Position after stop: " + clip.getFramePosition());
    Thread.sleep(1000);
    clip.start();			// and start again
    while(clip.isRunning());	// wait for the sound to finish
    System.out.println("Position at end: " + clip.getFramePosition());
  }
}

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

CUSTOMER SUBMITTED WORKAROUND :
Removing the comment for "clip.setFramePosition(pos);" in the supplied code fixes the bug.

Release Regression From : tiger-beta2
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Incident Review ID: 282073) 
======================================================================

Comments
EVALUATION This bug has several causes/issues: 1) Main problem: Clip.getFramePosition() is defined as the number of frames rendered since opening the device. Not very intuitive, but that's the spec. 2) The test program uses default buffer size, i.e. 500 milliseconds. It waits 1 second before it stops the device, so it hits a race condition: either the 3 buffer of 500 millis could just be written, or not. If yes, then the frame position will advance by the buffer size. This is a slight bug -- because that buffer is not actually rendered. Out of coincidence, the test program creates a race condition. 3) An "easy" fix would be a stop() implementation like this: store current position, stop device, set to stored position. However, and that's the problem, getFramePosition may return something completely meaningless with regards to setFramePosition, as outlined in 1). For a fix I suggest the following: A) in stop() record the position before stopping the device and use an internal setFramePosition method so that it returns the actual position that it was stopped, and continues counting from that position upon restart. B) amend the javadoc for Clip.getFramePosition() to always return a value between 0 and getFrameLength() (i.e. add a special case to DataLine.getLongFramePosition). C) Once B) is done, stop() can just set the frame position that it stored before stopping the device. Due to code freeze, this cannot be fixed for tiger, but should go into the next possible release. ###@###.### 2004-07-12 The cause of the bug is in the DirectSound Clip main playback loop implementation (DirectSoundDevice.DirectClip.run()): The most part of time loop works inside write(...) method (waiting until DirectSound buffer has space to write data). When stop() has been called during write(...) call java DS buffer counter (clipBytePosition) isn't increased although some portion of data has been written sucessfully. From the point DirectSound buffer position and java buffer position (clipBytePosition) became disagreed. ###@###.### 2005-07-08 10:00:40 GMT
08-07-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
15-08-2004

PUBLIC COMMENTS Too late for tiger, should get fixed in the next version.
15-08-2004