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?

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]

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

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?

What Bug ID did you get? I couldn't find it in the bug parade (or is it too soon?).

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 :(

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.

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 :(

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 f*cked on windows; Swing's paint routines are partially f*cked 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 :).

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.

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

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

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.

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

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?

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?

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.

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.

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:

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

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

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

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org