Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Add MP3 capabilities to Java Sound with SPI

The Service Provider Interface adds functionality to Java Sound without recoding

By Dan Becker, JavaWorld.com, 11/03/00

Thanks to a new feature in Java 2 1.3 -- the Java Service Provider Interface (SPI) -- the JVM provides audio subsystem information at runtime. Java Sound uses the SPI at runtime to provide sound mixers, file readers and writers, and format conversion utilities to a Java sound program. That allows older Java programs, even Java 1.02 programs, to take advantage of the newly added functions with no changes and no recompiling. Indeed, more functions can be added to Java Sound to take advantage of new file formats, popular compression methods, or even hardware-based sound processors.

In this article, we'll look at the SPI illustrated with a real world example: Java Sound extended to read, convert, and play MP3 sound files.

Note: To download the complete source code for this article, see Resources.

To understand the Service Provider Interface (SPI), it helps to think of a JVM as a provider of services to a Java program -- the consumer of those services. The consumer uses a known interface to request a JVM-provided service. For instance, with Java Sound the Java program requests to play an audio file with one of the public sound methods. In Java 2 version 1.3, the AudioSystem queries itself to see if it can handle the given sound file type. If it can, the sound is played. If it cannot, an exception is thrown, typically the sun.audio.InvalidAudioException for older Java audio programs that use the sun.audio or java.applet packages. In contrast, newer Java Sound programs that use the javax.sound package typically throw the javax.sound.sampled.UnsupportedAudioException. Either way, the JVM is telling you it cannot provide the requested service.

In Java 2 version 1.2, the sound subsystem was enhanced to handle audio files of many types: WAV, AIFF, MIDI, and most AU types. With that enhancement -- as if by magic -- the older programs that use the sun.audio or java.applet packages were able to handle new audio file types. That development represented a blessing to Java audio users, but it still did not allow users to extend the JVM. Java audio programs were still limited to the audio file types provided by the JVM maker.

With Java 2 version 1.3's SPI, we see an architected method of extending the JVM. Java Sound knows how to query those service providers and, when presented with an audio file, one of the service providers may indicate that it knows how to read the audio file type or knows how to convert it. Then the sound subsystem uses that service provider to play the sound.

Next, we examine how to add new service providers to take advantage of one popular audio file type, the MP3 or MPEG Layer 3 audio type developed in the Motion Picture Expert Group ISO standard released several years ago.