Hi, I'm hoping that someone out there can share their experience and
perhaps let me know why I'm having problems trying to play several 1-
second sound clips in a Java 1.5 applet. In particular, I'm having
different kinds of problems on the Mac vs. the PC. By the way, I'm
writing this application for an academic lab that would like to
conduct language learning experiments over the web using a Java
applet.

I'm just going to list the performance problems that I've had (and not
yet solved), and if anyone can give me either a solution to any of
them or just let me know that there *is* no known solution, I would
appreciate it!

I'm doing my development on the PC, and here are the problems I've had
on that platform:

1. If I open a SourceDataLine and leave it open for multiple (that is,
hundreds) of write() calls, with calls to drain() interspersed
periodically (as required by the design of my application), then I'll
eventually get a fraction of a second of a sound repeating every 5
seconds or so, independent of the continued calls to write() (which
succeed and cause new sounds to be played).

2. To deal with this, I tried creating a SourceDataLine for each
individual sound clip I need to play, call write(), then drain(), then
close(). But this introduces another problem: every once in a while,
there is an unexplained second or so of silence between sound clips.
The gap is too long to be explained by inopportune garbage collection.

On the Mac, the situation is even worse.

3. (Mac only.) If I create a new SourceDataLine for each clip, as in
problem #2 above, then I get a new thread which never goes away
(close() seems to have no effect). If I play 20 cilps, I have 20 new
threads. This is obviously unacceptable if I'm going to play hundreds
of clips.

4. (Mac only.) The sound clips come from little MP3s, which I decode
using JLayer 1.0. If I decode them on the fly, I get loud, annoying
clicking sounds at the end of the 4th or 5th clip, and every clip
thereafter. Further testing shows that the computer is amply able to
decode fast enough to keep the sound buffer full. I temporarily solved
this problem by decoding all the clips into memory first (before
playing any of them), and then playing the clips directly from memory,
but this will not be practical for us in the long run. I think this
problem has to do with competition for CPU time among the threads.

Again, any information would be most helpful, thanks!

Samuel