FULL PRODUCT VERSION :
1.5.0
1.5.0_01-b08

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]
Windows 2000 SP4

EXTRA RELEVANT SYSTEM CONFIGURATION :
Tested audio cards (interfaces):
SoundBlaster 64 AWE
M-Audio MobilePre USB
M-Audio FireWire 410

A DESCRIPTION OF THE PROBLEM :
The JavaSound DirectSound TargetDataLine sometimes drops some audio data.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
We used a slightly modified version of SimpleAudioRecorder.java from jsresources.org and
recorded 50 audio files with 20 seconds length each. Audio format was: PCM_SIGNED 44.1 kHz 16bit  stereo. We connected a sine wave generator with 377 Hz to the input of the audio interfaces.
The dropouts are visible in the signal plot of the recordings and they produce hearable klicks.

  To automate the tests we used a script for the signal and speech analysis program Praat (www.praat.org). The script applys a high-pass filter with cut-off frequency 500 Hz, which mainly filters the recorded sine wave. Next it measuers the intensity of the whole file. Dropouts in the signal cause some energy in the upper frequncy bands, so the intensity of broken files is much higher. Tested platforms are Windows 2000 and XP and three different audio interfaces. With line.available() we checked for bufferoverruns, but the buffer was appr. filled 60 % at most.
Using an own JavaSound mixer adapter for the ASIO interface the recordings are correct even with higher OS loads. So I think it is a bug in the DirectSound to javaSound code.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
We expected clear recordings.
ACTUAL -
Some audio files have dropouts.

REPRODUCIBILITY :
This bug can be reproduced occasionally.

---------- BEGIN SOURCE ----------
SimpleAudioRecorder.java from www.jsresources.org
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use JRE 1.4.2 for audio recording.
  xxxxx@xxxxx   2005-04-26 14:12:24 GMT

N/A

annoying bug
cause is not known
required investigating & fixing

  xxxxx@xxxxx   2005-07-18 09:47:29 GMT
Bug in DirectSound TargetDataLine implementation that can drop little pieces of captured data near DirectSound buffer bound
Posted Date : 2005-09-06 13:03:54.0

Perhaps related to this: there seems to be a bug in the blocking behaviour with JRE 5.0 when trying to read data during audio capture, if you use line.read and rely on blocking there will be occasional dropouts in the returned data (maybe every 10 seconds or so). Most reliable solution I have found is to have the capture task use the available() method to check the buffer status and let the task sleep until there is a block's worth of data to be read, so that the blocking behaviour is never required. That cured the dropouts for me. 

Maybe this is another problem. I tested recording with a a capture engine, which calls line.read(buf,offs,len) only if line.available() > 0 but I got the same errors.

I think I located the problem in PLATFORM_API_WinOS_DirectSound.cpp (from JDK6.0b43):

res = info->captureBuffer->Lock(thisReadPos, byteSize,
                                        (LPVOID *) &buffer1, &buffer1len,
                                        (LPVOID *) &buffer2, &buffer2len,
                                        0);
	if (res != DS_OK) {
	    /* can't recover from error */
	    byteSize = 0;
	}

Every time  I get a dropout in my recording, the Lock method returns a value not equal to DS_OK. 

The variable thisReadPos is not reset to zero if it is equal to dsBufferSizeInBytes. The Lock method is then called with this value and returns an invalid param error DS_INVALIDPARAM.
The condidtion for the update read pos loop should be
thisReadPos >= info->dsBufferSizeInBytes instead of
thisReadPos > dsBufferSizeInBytes
There are no dropouts in my test recordings using this fix. 

 

I submitted a patch for Mustang to dev.java.net, but it would be nice to have the fix also in a Tiger update.