JDK-5101898 : REGRESSION: J2SE 5.0 causes stuttering audio in other programs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 5.0,6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-09-14
  • Updated: 2012-10-08
  • Resolved: 2005-09-22
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.0u6Fixed 6 b53Fixed
Description
Name: rmT116609			Date: 09/14/2004


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

ADDITIONAL OS VERSION INFORMATION :
Windows XP Pro 32 bit
AMD 64 processor


EXTRA RELEVANT SYSTEM CONFIGURATION :
Echo Audio

A DESCRIPTION OF THE PROBLEM :
When running any program with J2SE 5 RC, audio is repeatedly distorted.  Pauses happen repeatedly during playback; what seems to be happening is that the VM is stealing all of the CPU, somehow, which causes a pause in playback.  The effect is lessened but not eliminated by reducing the priority of the Java process.  The exact same programs run with the 1.4 JDK do NOT exhibit this characteristic.  I've run Eclipse within J2SE 5 and within JDK 1.4.2_05.  It seems that whenever certain bits of code are touched for the first (or an early) time the stuttering occurs.  This led me to believe that it was either the JIT or the shared class mechanism that was causing the problem.  I turned off the shared class mechanism, re-ran Eclipse under J2SE 5, and the problem still occurred.  I have not yet turned on detailed compilation information and done the test, but I will shortly.

I've also noticed that at the same time as the audio pauses, the entire PC "freezes" slightly -- the mouse cursor locks in place, indicating that something has frozen the machine in a timeout.  Once again, this problem ONLY occurs when using the J2SE 5 VM.  No such pause occurs with JDK 1.4.

This problem makes it impossible to play back any kind of audio in another program while a Java program is running under J2SE 5, when using Echo Audio.  On a completely different PC, with a different sound system, I have noticed very minor clicks and pops, but nothing like the major pauses that occur.

This may be a bad interaction with the Echo Audio drivers.  The EA drivers may be particularly inefficient, making a problem present with many drivers more obvious.  It may be an interaction with AMD64.  I will try to provide additional information.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Begin MP3 (or any other audio format) playback.  Run any java vm-based program, such as Eclipse.  Listen for pauses in playback of the audio, and/or freezes on the mouse cursor.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No pauses, perfect audio playback, same as JDK 1.4.
ACTUAL -
Pauses in playback, slight "freezes" in the cursor and the entire system.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
no error messages occur.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Audio stuttering always occurs in J2SE 5.  No stuttering in JDK 1.4.

Release Regression From : 1.4
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: 310651) 
======================================================================

Comments
EVALUATION Fixed by mapping Java Thread.MAX_PRIORITY to Windows THREAD_PRIORITY_HIGHEST instead of THREAD_PRIORITY_TIME_CRITICAL. If an application really neads TIME_CRITICAL thread, it can set -XX:ThreadPriorityPolicy=1 to switch back to the old behavior. ThreadPriorityPolicy controls how JVM uses thread priorities, 0 is appropriate for normal applications; 1 is for applications that really want to map to the entire native priority range. Note that -XX:ThreadPriorityPolicy=1 must be used with care; depending on the application and system load, it may actually hurt performance of the application and/or system. I have also lowered most VM internal threads' priorities, as they can be CPU intensive and should never run at THREAD_PRIORITY_TIME_CRITICAL (even with -XX:ThreadPriorityPolicy=1).
2005-09-14

EVALUATION Have customer try this flag -XX:-UseThreadPriorities? Or -XX:JavaPriority10_To_OSPriority=10 -XX:JavaPriority9_To_OSPriority=9
2005-08-09

EVALUATION This bug is incorrectly categorized under java:classes_sound. Sound is not playing within the Java VM. The problem is not related to the Echo audio hardware - the same happens with other hardware. The J2SE 5 VM is distorting sound being played by OTHER applications as well as freezeing mouse. I'm changing category to VM (not sure about right subcategory). ###@###.### 2005-07-11 15:13:56 GMT
2005-07-11