Are audioclips that slow?

Java Sound & OpenAL
#1

Hi,

This is my first post, and I’m a total beginner when it comes to Java. But I’m working on a basic-style programming language for Windows (http://www.naalaa.com). I recently made it possible for the compiler to generate java code (applets) instead of standalone executable files. There are some problems regarding sound though.

As soon as play is called for an Audioclip, the applets slow down a lot. I know that the audio isn’t loaded until it’s played for the first time, but that’s not the problem in this case. As long as any audioclip is playing the applets run slowly. If no clip has been played for a while, the speed returns to normal. I’ve tested the applets on several computers, and the only one that managed not to slow down had four really fast processors. Playing an audioclip shouldn’t really require that, right?

This is an example applet with sound: http://www.naalaa.com/applets/Blastemroids.html

And this is the same applet but without sound: http://www.naalaa.com/applets/BlastemroidsNS.html

Are audioclips slow, or could it be something else? For example, the code uses System.currentTimeMillis() in combination with Thread.sleep(…) to maintain a constant fps. Are those reliable, or can they be affected by the sound playback (which I assume is performed in another thread somewhere)?

Would it help to use the java sound api instead?

/Marcus

#2

[quote]Are audioclips slow, or could it be something else?
[/quote]
even if AudioClip use a little of CPU it should not slowdown your Applet

[quote]the code uses System.currentTimeMillis() in combination with Thread.sleep(…) to maintain a constant fps. Are those reliable,
[/quote]
not really, System.currentTimeMillis() have a high granularity on most window platform (approx16ms), Thread.sleep is not a lot better,even with this low precision your main loop could work fine depending on how you use/implement it, but you should not expect them to work as they should.

Would it help to use the java  sound api instead?

there are some alternative in recent JVM for both AudioClip & System.currentTimeMillis : java sound & currentTimeNanos, it is depending on your JVM target version

#3

side note : on my computer, the Applet with sound use exaclty the same amount of CPU than the one without sound : 25% for both

#4

This isn’t really related to your problem, but I thought you’d probably find the information useful anyway. I tested your applets in IE 8 under Windows XP, and I couldn’t see any visible difference in frame-rate between the sound and the non-sound versions. I also tested the applets in both 64-bit and 32-bit Firefox browsers under Ubuntu Karmic 64-bit, and the sound did not play (Java Console shows that the audio files were loaded, but no audio plays). I could not see a difference in frame-rate between the sound and non-sound versions on these browsers, either.

#5

[quote=“NaaLaa,post:1,topic:35007”]
IMO, the preferred solution for situations in which changes in the frame-rate affect the movement speed of objects, is not to use a Thread.sleep to limit the framerate. Instead, you should use the system time at the start of each frame to determine where the objects should be based on DistancePerMillisecond variables. I use this method all the time with great reliability in my games for moving objects, performing animations, etc.

[quote=“NaaLaa,post:1,topic:35007”]
I have no experience with Audioclip, so I don’t know if switching to Java Sound would fix your framerate problem, but it might be worth a try. It would at least solve the compatibility problem that I pointed out (no sound in Firefox under Ubuntu).

#6

this is not an authorative statement but:

  1. audio clips in f.ex shooter game, spawning clips for sounds will not work nicely without advanced treatment apparently ( basic java api sound clip play ).

  2. currentTime as DzzD says is very unaccurate by todays standards: 16ms, even if it was 6 ms is still too unaccurate for todays 300+ fps. Assuming ms is accurate may cause problems if fps is higher than the accuracy of the timer.

#7

[quote=“Karmington,post:6,topic:35007”]
Exactly. This is why I suggest using the system time not to limit the frame rate, but rather for determining where an object should be based on its velocity. Even if the system time only changes every 16ms, any frames that happen during the 16ms between timer updates will calculate that 0ms passed since the last frame. This prevents the object from “jumping around” at random speeds just because the frame rate was fast or slow.

#8

There are many ways to maintain constant speed in a game :slight_smile: In the examples for this programming language I use the sleep-technique because it’s simple and clean.

Those of you who’ve tested the applets and replied to my post claim that there’s no difference in fps between the two versions (with and without sound). And that makes me happy, of course :slight_smile: But on my computer, and as good as on every other computer (new or really old) that I’ve tested the example applet on, there’s a nasty difference. The only difference in the code generated by my programming language is that play is called for some audioclips in the version that runs slow. That’s all I can say for sure. The cpu usage is about 4% for both examples.

My memory is bad, but I believe the applet versions ran fine when I used high quality wav files instead of badly compressed au files.

#9

could you check CPU usage for both version for the computers having problems ? (and just in case of, also post how many cpu they have : 50% on dual core will means 100% for a single threaded program on window)

a notice about constant FPS if it may help : I never try to get a constant FPS but always use a constant logic rate , I dont like the idea of merging logic/graphic or the idea of logic depending on something graphic related.

using such fixed logic rate with varaible FPS have a cupple of advantages :

  • it will ensure you get exact same result on very slow computer (unable to match your requested FPS) aswell as very fast and will able people having a better hardware to get a higer FPS
  • it will enable slow & fast computer to play together throught network at different FPS (like any network FPS/RTS/etc… you may play)
  • and most important it does not requiere high precision timer (System.currentTieMillis will do the job well)

I will sent a code snipet later if you’re interrested

#10

Hi again!

The cpu usage without sound bumps between 3 and 4% on my computer (single processor) under Windows 7. With sound its around 5%. So I don’t think that the audioclips are the direct cause of the problem.

I’ve made some prints to test the accuracy of the timer and the sleep. The accuracy of the timer actually seems to be 1 ms. But telling the thread to sleep for 1, 5 or 10 ms all seem to actually make it sleep for 15 ms. So I’m assuming that thread.sleep is the burglar. Are there any options when you want to pause your thread that doesn’t eat up a lot of cpu?

I too prefer to use timer based multiplications in the logic to maintain a constant speed. But I’m not trying to make a game here (I only make games at my job, this naalaa-thing, a programming language for beginners, is just something I do at my spare time). For simple 2D games with very low amounts of blittings, such as this example, I believe sleeping is a very simple and reliable way of keeping a constant speed. There’s actually no performance difference between running the applet on an old 400Mhz computer and this multigigahertz-thingie that I’m using now. And if I still had my good old 14Mhz Amiga-computer, I bet it would run fine there too … if could only make it sleep for the number of ms that I want :slight_smile:

#11

other running program/thread may increase the inacuracy of thread.sleep so I suppose that when the audioclip thread is running it change your sleep lenght and you get the felling of a lower FPS.

once again becarefull that having System.currentTimeMillis working on your computer does not means they will do the same everywhere & same for sleep : always consider that they are working weird when using them in a program.
I would use a Thread.sleep(1) in the main loop (to avoid eating all cpu) and control/manage the FPS with the timer (not Sleep) something like :

 while(true){while(getCurrentTimeMs()<nextFrameTimeMs) Thread.sleep(1);drawOneFrame();nextFrameTime+=40;} (for 25 FPS)
#12

Sorry for the late reply. But when an audioclip is playing, sleep(1) makes the thread sleep for 15ms, so I can’t use that technique either. Isn’t it kind of hopeless that you can’t trust sleep or timers?

#13

I would say that 15 ms is still ok with this technic, no?
(still > 60fps : anyway note that also with the above code they will be no execution of the sleep(1) statement if more FPS is requiered)

#14

Aaah! Me so stupid. You’re right, that works much better :slight_smile: Thanks a bundle!