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) 
======================================================================
Posted Date : 2005-08-09 17:28:43.0

N/A

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).

  xxxxx@xxxxx   2005-07-11 15:13:56 GMT
Have customer try this flag -XX:-UseThreadPriorities?
Or -XX:JavaPriority10_To_OSPriority=10 -XX:JavaPriority9_To_OSPriority=9
Posted Date : 2005-08-09 17:29:31.0

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).
Posted Date : 2005-09-14 21:13:31.0

I've noticed the same effect on my work machine as well -- with a completely different audio driver (same OS).

This bug is incorrectly categorized under java:classes_sound.  In my example, sound is not playing within the Java VM.  The J2SE 5 VM is distorting sound being played by OTHER applications.

Same for me but I think the problem is not with sound ; the real problem is JDK1.5 uses more CPU (sometimes 100% !!!) than JDK1.4. 

But the effect on sound players like Winamp is immediate : sound is distorded or stopped.

I

I've tested on 1.5.0_01 and had the same stuttering effect on several PCs.  Loading a big project into Eclipse is a good way to reproduce this...as Eclipse's VM compiles code, the mouse cursor becomes very "stuttery" until compilation is complete.  This problem is not related to the Echo audio hardware at all -- it's something else.  During compilation the JDK 1.5 VM's hotspot locks something down that causes the entire system to freeze up briefly, perhaps just milliseconds...

Thanks for fixing this!  It was driving me nuts.  :)  

The flags suggested work perfectly for the existing 1.5 releases.  

Note that it can be exceedingly dangerous to use CRITICAL or REALTIME priorities under Windows...let's just say that I once wrote a device driver over a month, was busy testing, and just decided to see what effect those flags would have...resulted in a trashed hard drive as sector writes got inhibited, and a lifelong lesson learned...

Note that as of today (see date) Eclipse recommends running with 1.4.x, not 1.5. You can compile against 1.5, but they don't recommend it for running the IDE.

This is an issue in 1.4 and all previous versions as well. It is just not as extreme in 1.4.  The System.gc() (call among) others in older versions will still cause a pause in some cases.

The freeze piece of this defect is still occuring on the 64-bit 5u6 running under Win2k3 Server.  With a 28G heap the server becomes non-responsive for several minutes.

This bug has returned with a serious vengeance in JRE6.0