Name: boT120536 Date: 12/28/2000


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)


HW: Soundblaster AWE-64, Solaris standard "sbpro" driver


No audible sound effects on solaris 8 x86 (intel) using jdk 1.3.0 and various
programs. It seems this problem happens when using 16-bit PCM, 44.1kHz
sound format.


Example 1:
==========

import javax.sound.midi.*;
import javax.sound.sampled.*;

public class jsound {
    public static void main(String[] args) throws Exception {
        Sequencer sequencer = MidiSystem.getSequencer();
        Mixer mixer = AudioSystem.getMixer(null);

        java.io.BufferedInputStream is =
            new java.io.BufferedInputStream(
                new java.io.FileInputStream(
                    new
java.io.File("/usr/j2se/demo/jfc/Java2D/media/ambient.rmf")),
                1024);
        sequencer.open();
        sequencer.setSequence(is);
        sequencer.start();
    }
}


This program should play a midi file (from the jdk1.3.0 demo directory).
No sound can be heard on Solaris 8 (x86).
Sound playback is OK with this example program using Solaris 8 (SPARC).


Example 2:
==========

Try to playback an MP3 file using the jmf-2.1.1-beta3 java media player.
There's no audible sound on Solaris 8 x86


Note: For both examples, when you run sdtaudiocontrol in the background
you'll notice on the status window that the hardware is playing samples
all the time (the "Samples" counter gets incremented all the time while the
java vm should playback some sounds). Using 'truss' on the jvm process
reveals that lots of 0 bytes are sent to the /dev/audio device (constant
stream of 0 bytes => thus no audible sound!)
(Review ID: 114341)
======================================================================

Name: boT120536 Date: 02/23/2001


java version "1.3.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-beta-b15)
Java HotSpot(TM) Client VM (build 1.3.1beta-b15, mixed mode)


This is a followup to bug-id 4400938 (including a SCSL bug fix for
the problem).

The problem reported in 4400938 for jdk 1.3.0 is present in jdk-1.3.1-beta
on solaris 8 (x86), too.
So the jdk version "1.3.1-beta" can be added to the "reported against"
field.


There are actually two problems:

1. a compiler bug (a test in file GenAudioStream.c is using condition
   codes that are destroyed by a structure copy)

2. definition of byte order is not correct on solaris x86 (uses sparc
   byte order to load the jre/lib/audio/soundbank.gm file -> and fails)

   (An "#ifdef X86" was added in the j2se 1.3.1-beta source in an attempt
   to fix this problem, but "X86" is not defined, so the behaviour is still
   unchanged from j2se 1.3.0)



                 =======================
Additional information for the compiler bug (1. above):
                 =======================


It's obviously a compiler bug in the x86 workshop compiler that is
used to compile the intel JDK1.3.0 FCS release!


The problematic piece of code can be found in
share/native/com/sun/media/sound/engine/GenAudioStreams.c, function
GM_AudioStreamService(), lines 2544++. There we have the following
piece of code:

pStream->streamMode &= (~STREAM_MODE_INTERRUPT_ACTIVE);
        ssData = pStream->streamData;
        switch (pStream->streamMode)
        {
            default:
         ...
            case STREAM_MODE_FREE_STREAM:
         ...
            case STREAM_MODE_STOP_STREAM:
         ...
            case STREAM_MODE_DEAD: /* STREAM_MODE_DEAD is defined as 0! */
         ...
...
        }

This piece of source code is compiled into the following assembler code:


% adb /tmp/j2sdk1_3_0/jre/lib/i386/libjsound.so
GM_AudioStreamService+1a7,20?ia

/* pStream->streamMode &= (~STREAM_MODE_INTERRUPT_ACTIVE); */

GM_AudioStreamService+0x1a7: movb 0x58(%esi),%al [0x58,-]
[1]--> GM_AudioStreamService+0x1aa: andb $0x7f,%al [0x7f,-]
GM_AudioStreamService+0x1ac: movb %al,0x58(%esi) [-,0x58]

/* ssData = pStream->streamData; */

GM_AudioStreamService+0x1af: leal -0x28(%ebp),%edi [0xffffffd8,-]
GM_AudioStreamService+0x1b2: pushl %esi
GM_AudioStreamService+0x1b3: pushl %edi
GM_AudioStreamService+0x1b4: leal -0x28(%ebp),%edi [0xffffffd8,-]
[2]--> GM_AudioStreamService+0x1b7: addl $0x18,%esi [0x18,-]
GM_AudioStreamService+0x1ba: cld
GM_AudioStreamService+0x1bb: movl $0x8,%ecx [8,-]
GM_AudioStreamService+0x1c0: repz movsl (%esi),(%edi)
GM_AudioStreamService+0x1c2: popl %edi
GM_AudioStreamService+0x1c3: popl %esi

/* switch (pStream->streamMode) */

[3]--> GM_AudioStreamService+0x1c4: jne .+0x2bb <0x17c67>
[GM_AudioStreamService+0x47f]

/* case STREAM_MODE_DEAD: */

GM_AudioStreamService+0x1ca: movl 0x40(%esi),%eax [0x40,-]
GM_AudioStreamService+0x1cd: movl %eax,-0x1c(%ebp) [-,0xffffffe4]
GM_AudioStreamService+0x1d0: movl 0x48(%esi),%eax [0x48,-]
GM_AudioStreamService+0x1d3: movl %eax,-0x20(%ebp) [-,0xffffffe0]


The code generated by the x86 compiler is bad because:

The compiled switch starts by jumping over the "case STREAM_MODE_DEAD:"
part with the 'jne' instruction marked [3]. (Note: STREAM_MODE_DEAD is
defined as 0). The idea was obviously to re-use the conditions codes
set up by the 'andb' instruction marked [1]. Problem is, that the
block move for the structure assigment contains the 'add' instruction
marked [2] that destroys the ZERO condition code (0x0040 bit) in the
processor's status register.

So, if pStream->streamMode has the value STREAM_MODE_DEAD, the compiled
code will *not* execute the code after the 'case STREAM_MODE_DEAD:'
label, but will drop into the 'default:' branch!

TEST CASE:
4400938 contains a test case.

Or try to run the JSDK's demo/sound/JavaSound.jar application on solaris 8 x86.
There's no audible sound output.

A third test case is JMF 2.1.1-beta3. This version cannot play .mp3 files,
again you hear silence during playback.


RELATED BUGS:
4400938
(Review ID: 117562)
======================================================================