0

even thought java is backwards compatible, I have problems running my Java 6 application using JRE7.

First problem:

javax.sound.sampled.Clip simply doesn't work when I run using JRE7, but works perfectly when I run using JRE6.

        AudioInputStream inputStream = null;
        //Try statement
        inputStream = AudioSystem.getAudioInputStream(new ByteArrayInputStream(buffer));
        clip = AudioSystem.getClip();
        clip.open(inputStream);

        if (delay > 0) {
            Thread.sleep(delay);
        }
        clip.start();
        //catch statement

On JR7, after clip.start(); clip.isRunning() returns false; which doesn't happens when running on JRE6

Second problem:

I compress my image pixels using java.util.zip.Inflater, however using JRE7, when read the pixels, the red channel comes wrong for some reason that I couldn't figure out.

Probably because Inflater use zip library (jre\bin\zip.dll) which is different between jre6 and jre7

Checked using: System.getProperty("java.version"):

Java Runtime Version: 1.6.0_24

  • Sound works perfectly

  • Images load perfectly fine

Java Runtime Version: 1.7.0_21

  • Sound doesn't work (Actually it randomly plays)

  • Images load perfectly fine

Java Runtime Version: 1.7.0-ea

  • Sound works perfectly

  • Images load with incorrect red channel.

Simple test:

Using this code for both java version: http://pastebin.com/WMCfh4Vp

Result:

  • JRE-6: Works
  • JRE-7: Doesn't play, say that clip is not running nor is active.

There's a way to turn around this problem?

Thank you.

Pb600
  • 130
  • 1
  • 5

2 Answers2

0

I suspect that the problem is in the way you are handling the bytes (e.g. encoding, transmission, etcetera) ... not in the compression library or the audio or image libraries.

(UPDATE - your pastebin link doesn't include your FileOperations class. If there was a problem with the way you were handling the bytes, it would most likely be in there!)

If the bytes are being handled correctly, then another possibility is that the system (or JRE) where the playback is failing doesn't have the necessary audio codecs.

Either way, you need to provide more code (ideally a pair of SSCCE's) if you want a detailed answer.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I think it's hard to be data problem, since the data bytes are exactly the same, however to test your theory, I made it load a sound that I downloaded from somewhere. Code: http://pastebin.com/JLQ7mrV1 -Result from exactly the same code and different JRE versions: Java Runtime Version: 1.7.0-ea Playing audio Audio is playing: false active: false open: true Java Runtime Version: 1.6.0_24 Playing audio Audio is playing: true active: true open: true – Pb600 Sep 02 '13 at 04:20
  • Okay, there goes: http://pastebin.com/WMCfh4Vp If I compile this code on Java 6, I'll be able to listen to the sound using JRE-6, however I won't be able to listen to the sound at Java 7, the output of the flags will be different. By the way, the problem doesn't happen only to me, I figured out about this problem because of users reporting to me. – Pb600 Sep 02 '13 at 05:24
  • Actually I did try a few different audio formats, I saw something about that JDK 7 makes all music thread daemon, still don't see how this affect, but I see a lot of people failing to play music on JRE 7. And to show that it's not any file problem, there's this piece of code from tag wiki, that happens same thing, works on JRE6 and not JRE7 - http://stackoverflow.com/tags/javasound/info – Pb600 Sep 02 '13 at 05:57
0

The problem was that I was checking if it was running right after put to play, what happens is that on Java 7 you have to put the thread to sleep before checking if it's playing in order to let it on a recurrent sleep.

Pb600
  • 130
  • 1
  • 5