javax.sound.sampled 1.4.1 problem

Java Sound & OpenAL
#1

When playing sampled sounds using the Windows java 1.4.1 virtual machine, sounds play back incorrectly and the sound thread blocks all other goings-on, causing the main game thread to slow down and chop madly. After some testing I’ve concluded that this problem does not exist under the Windows 1.4.0_* runtimes and all other previous runtimes that implement javax.sound.sampled.

Am I doing something wrong? Or is the new runtime just horribly flawed?

I’ve posted an example jar (source included) that demonstrates the problem at
http://www.zianet.com/emeasure/SoundTest.jar

To run:
java -jar SoundTest.jar
p to play sound
arrow keys to move oval (demonstrates choppiness)

Relevant code:

private Clip clip;

private final void initializeClip()
{
try
{
AudioInputStream stream =
AudioSystem.getAudioInputStream( getClass().getResource( “test.wav” ) );

        AudioFormat format = stream.getFormat();
        
        DataLine.Info info = new DataLine.Info(
        Clip.class, stream.getFormat(), ( (int) stream.getFrameLength() * format.getFrameSize() ) );
        clip = (Clip) AudioSystem.getLine( info );
        
        // Wait until audio file completely loaded
        clip.open( stream );
  } catch( Exception e )
  {
        e.printStackTrace();
  }

}

private final void playClip()
{
clip.setFramePosition( 0 );
clip.loop( 0 );
}

Thanks in advance for any insights you can provide,
lamster

#2

Tried your test and I got the same problem.
In fact I have very bad experiences with javax.sound since java 1.3 myself. Sound always lags behind and you will give your program a huge slow down. I also tried to use continuous sound streams using javax.sound.sampled in an emulator. No way to get that to behave like expected.
If I were you I’d give open-al a try.

[rant]
I think Sun should stop adding features for a while and start making their java platform stable, reliable and well performing.
[/rant]

#3

lamster - haven’t tried yours but I can confirm it with my own game. Ran smooth as silk under 1.4.0 - under 1.4.1 whenever I hit a clip.start() - I get a small pause (thought it was the GC but then debugged it down to that line). If I comment out that line (effectively disabling the playing of my clips) - then everything runs smooth again…

#4

Thanks for the confirmation guys,

I’ve submitted the bug to the java parade, let’s
hope it’s dealt with in 1.4.2.

#5

I’m having this problem in my game too… Every time a sound is played, the game stutters horribly :’(

What Bug ID did you get? I couldn’t find it in the bug parade (or is it too soon?). I read another bug report (Bug ID 4190660) about the sound device not being released after the clips stopped, and that it had been fixed by remodeling the internal behaviour of applet.AudioClip. Maybe this new bug is related to the previous bugfix?

#6

It’s too soon yet; I’ll post the pertinent infos to this thread as soon as the bug team sends me a response. Sun claims typical processing time of about 3 weeks for new bug reports, so expect to wait until at least March 2nd for the update.

In the meantime you can always test your stuff with 1.4.0_03 (http://java.sun.com/j2se/1.4/download.html), but it’ll be painful to have to try to distribute an obsolete java as a prerequisite for a release game :frowning:

#7

I have the same problem, also i have tried with jmf 2.1.1 but the result is like jdk, so for now i use the “hidden” class <sun.applet.AppletAudioClip>.
I know its not the best solution but it work fine for me,
i hope it works fine for you. :slight_smile:

#8

FYI - still broken in 1.4.1_02

#9

You really do not want to get people to use 1.4.0. It’s utterly utterly rubbish; it’s full of really major bugs (NIO is fcked on windows; Swing’s paint routines are partially fcked on windows - I have example apps that paint funky animations on 1.4.1, and on 1.4.0 you get a black screen.). Look at the bugfixes list for 1.4.1, and you should be able to spot some howlers :).

#10

[quote]I have the same problem, also i have tried with jmf 2.1.1 but the result is like jdk, so for now i use the “hidden” class <sun.applet.AppletAudioClip>.
I know its not the best solution but it work fine for me,
i hope it works fine for you. :slight_smile:
[/quote]
Have you tried the NON hidden Applet .newAudioClip(…) method(s)? The ones that are officially sanctioned by Sun? I’ve not started using the JMF audio (I’ve heard too many horror stories ;)), so forgive my ignorance if there’s some reason they’d be uselss for you. However, I find they work perfectly for playing up to about 5 sounds simultaneously…


      java.net.URL url = getClass().getResource( "clockticks.wav" );
      clockTick = Applet.newAudioClip( url );
      clockTick.play(); // clockTick.loop() or whatever...
#11

The reason i dont use newAudioClip is because i want create many AudioClips sharing the same data, so i have the data file in memory and use the constructor sun.applet.AppletAudioClip(byte[]).

All methods i found in jdk need an URL, anybody know a better form to do this?

I think jmf is really bad for play sound, although with video it work fine.

bye!

#12

I don’t understand - what’s the point? How is this different from using the standard library newAudioClip (except that it is non-standard)?

If you create one clip normally, the data file will probably be “in memory” (thanks to disk caching). Once the clips are created, have you saved any memory? Isn’t each clip object still going to need it’s own copy of the clip data?

#13

First i have in memory the clip data in a byte array, and then i create all the audioclips using that array.
How u say, “the data file file will probably be in memory”, but i can not be sure of it, also if im in a low internet connection and the data is not in memory, probably the audio will sucks.

#14

I see now; I suggest you log a bug with Sun. The API docs ought to tell you whether you needed to do this at all, but they don’t…yet another lazy Sun developer wrote:

"newAudioClip

public static final AudioClip newAudioClip(URL url)

Get an audio clip from the given URL.

Parameters:
    url - points to the audio clip 
Returns:
    the audio clip at the specified URL.
Since:
    1.2"

This is NOT documentation, this is a piece of crap. The non-static AudioClip methods were written by someone marginally less lazy, and confess that they are not loaded until you attempt to play them. If the same is true of the static version, then you’ve obviously got a big problem with the static methods.

Sadly, AudioClip isn’t cloneable, and it’s unclear whether we should assume (from the lack of documentation) that AudioClips to the same URL do or don’t share their loaded data…

#15

If u see source of that method, the code is


public static final AudioClip newAudioClip(URL url)
{
return new sun.applet.AppletAudioClip(url);
}

, so it use the same class but with other constructor. And that class create a inputstream for each url, so i dont think the data is shared.
Maybe with javax.sound there are some manner to do that, but i dont know how…