This content has been marked as final. Show 5 replies
yes, the timers are not so precise. The most precise solution for this type of task is probably using separate thread. Se start your own thread and manage the timing from within your overriden Thread.run() method. Don't forget to keep sleeping the thread for the rest of the time otherwise you will get a performance problem.
thanks for replaying
i tried the additional thread, i got precise timing by that as i remember, but when the second thread was sleeping, i couldnt do anything in the main thread.
that is , it didnt respond to buttons and listeners in general.
did i make another thread that worked in a serial way? how do i make it go in parralell to my main thread?
If you write what you write then you probably didn't create the thread or you are running the code in synchronized methods. The only advice I can give you now is to learn the threads. The java.langThread javadoc should be enough, if not, then uncle Google will definitely help you to find million examples :-)
(don't know anything about j2me, but this could help, if available on that platform)
Hi, are you using Timer.scheduleAtFixedRate method (instead of schedule)?
The javadoc in that method can give you an idea of what's happening.
Probably the OS takes a lot of time (millis speaking) to play it (even with a small clip), taking os resources to play, releasing them, etc. Don't destroy the sound object, keep it on memory...
Try to change the process priority,as well, or use a shorter sound file.
Instead of the sound, test if you have the same problem with Toolkit.getDefaultToolkit().beep()