United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-5101898 : REGRESSION: J2SE 5.0 causes stuttering audio in other programs

Details
Type:
Bug
Submit Date:
2004-09-14
Status:
Closed
Updated Date:
2012-10-08
Project Name:
JDK
Resolved Date:
2005-09-22
Component:
hotspot
OS:
windows_xp
Sub-Component:
runtime
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
5.0,6
Fixed Versions:

Related Reports
Backport:

Sub Tasks

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

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
EVALUATION

Have customer try this flag -XX:-UseThreadPriorities?
Or -XX:JavaPriority10_To_OSPriority=10 -XX:JavaPriority9_To_OSPriority=9
                                     
2005-08-09
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



Hardware and Software, Engineered to Work Together