Some years ago, engineers working at NeXT (so we're led to believe) standardized a sound file format that many of us have come to know and love in the incarnation of millions of ".au" files that have spread all over the Net like a virus.

Sun Microsystems, naturally knowing a good thing when it saw it, decided to pick up the standard for themselves. Strangely enough, files of this format are now sometimes refered to as "Sun audio files."

This week, we're going to study how this pervasive little file format made its way into the Java API, while simultaneously resisting the urge to fill this entire article with loads of meaningless and annoying sound samples.

Of course, we need to be more specific, since a normal .au file can actually contain samples of a number of different types: The current API supports only 8-bit, µlaw, 8000Hz, one-channel .au files. If you were dreaming of slamming your audience with 50-megabyte 44 khz samples, you're out of luck--at least, with this version.

Coming up with these samples is relatively easy, since this sound format is (or has been, at least) a de facto standard for the World-Wide Web. Players, recorders, and processors for samples of this type are available everywhere, for most any computer platform. There happens to be an excellent FAQ regarding audio formats, how they work, and where to get them.

Similarly to the way images are treated, there are simple, straightforward methods for manipulating sounds within the java.applet.Applet class definition--supplemented by the AudioClip class. They will appear in some ways similar to last week's image-related methods, and for good reason. The programmer assigns a sound to an AudioClip variable, and then plays it. Additionally, there are simple provisions for looping the sound, as well as a shortcut method that just takes a URL and plays the sound it (hopefully) finds there. Basically:

• getAudioClip() is used to associate a sound somewhere on the Internet (pointed to by URL) with a variable in your program of type AudioClip.
• play() takes an AudioClip as an argument for playback. When passed (URL), it's also the shortcut method, defined out of java.applet.Applet instead of java.applet.AudioClip.
• loop() plays the AudioClip passed to it in a continuous loop until...
• stop() halts the looping play of the referenced AudioClip.

Also, as with last week, both getAudioClip and play can take (URL,string) instead of just (URL) as their argument; this is for the convenient use of the getCodeBase and getDocumentBase methods. See last week's column for a better explanation of how these methods are useful.

When programming with sounds, one needs to keep in mind that, as with images, just "getAudioClip"ing a sound file does not immediately cause it to be loaded so that it can await immediate playback on request. Moreover, causing a sound to play can halt your entire applet while the sound is loading, if you're not careful.

But this leads us to a logical conclusion, since halting your applet for some arbitrary amount of time (dictated by the healthiness of the Internet, in many cases) while your sound(s) load is unacceptable.

Threads
You may have heard of threads as a buzzword, or you may make use of them every day, but either way you'll find that with a basic understanding of the fundamentals behind them, they're blindingly simple to use in Java. Most of today's interesting Java applets use them extensively. For the uninitiated, threads allow you to have several separate pieces of code running simultaneously. Programs, instead of following a plain old linear flow through their instructions, can instead split apart and specialize. In this case, they can allow us to place our getAudioClip call in a separate method that we can run while the rest of our applet runs at the same time.

It doesn't stop there--extending the concept a little further, it's possible to imagine an applet that creates separate threads for handling animation, sounds, and user input. And this is only the beginning for the creative uses of multitasking within your applet. Perhaps you've noticed as we've talked about the Java user interface that all of its components are implemented in such a way that different objects can be controlled or monitored simultaneously by different threads. So, as we move toward understanding how some of the more clever applets on the Web actually work, threads will be integral for holding together all the other tools we find along the way.

Next week, thread basics. Stay tuned . . .

Past installments of Java Jolt