Accessing Audio System Resources

Here, the Line.Info would specify a TargetDataLine. The Line.Info class is discussed in the next section.

Getting a Line of a Desired Type

There are two ways to get a line:

• Directly from the AudioSystem object
• From a mixer that you have already obtained from the AudioSystem object

Getting a Line Directly from the AudioSystem

Let's assume you haven't obtained a mixer, and your program is a simple one that really only needs a certain kind of line; the details of the mixer don't matter to you. You can use the AudioSystem method:

static Line getLine(Line.Info info)

which is analogous to the getMixer method discussed previously. Unlike Mixer.Info , the Line.Info used as an argument doesn't store textual information to specify the desired line. Instead, it stores information about the class of line desired.

Line.Info is an abstract class, so you use one of its subclasses ( Port.Info or DataLine.Info ) to obtain a line. The following code excerpt uses the DataLine.Info subclass to obtain and open a target data line:

TargetDataLine line;
DataLine.Info info = new DataLine.Info(TargetDataLine.class, 
    format); // format is an AudioFormat object
if (!AudioSystem.isLineSupported(info)) {
    // Handle the error.
    }
    // Obtain and open the line.
try {
    line = (TargetDataLine) AudioSystem.getLine(info);
    line.open(format);
} catch (LineUnavailableException ex) {
        // Handle the error.
    //... 
}

This code obtains a TargetDataLine object without specifying any attributes other than its class and its audio format. You can use analogous code to obtain other kinds of lines. For a SourceDataLine or a Clip, just substitute that class for TargetDataLine as the class of the line variable, and also in the first argument to the DataLine.Info constructor.

For a Port, you can use static instances of Port.Info, in code like the following:

if (AudioSystem.isLineSupported(Port.Info.MICROPHONE)) {
    try {
        line = (Port) AudioSystem.getLine(
            Port.Info.MICROPHONE);
    }
}

Note the use of the method isLineSupported to see whether the mixer even has a line of the desired type.

Recall that a source line is an input to a mixer—namely, a Port object if the mixer represents an audio-input device, and a SourceDataLine or Clip object if the mixer represents an audio-output device. Similarly, a target line is an output of the mixer: a Port object for an audio-output mixer, and a TargetDataLine object for an audio-input mixer. What if a mixer doesn't connect to any external hardware device at all? For example, consider an internal or software-only mixer that gets audio from an application program and delivers its mixed audio back to the program. This kind of mixer has SourceDataLine or Clip objects for its input lines and TargetDataLine objects for its output lines.

You can also use the following AudioSystem methods to learn more about source and target lines of a specified type that are supported by any installed mixer:

static Line.Info[] getSourceLineInfo(Line.Info info)
static Line.Info[] getTargetLineInfo(Line.Info info)

Note that the array returned by each of these methods indicates unique types of lines, not necessarily all the lines. For example, if two of a mixer's lines, or two lines of different mixers, have identical Line.Info objects, the two lines will represented by only one Line.Info in the returned array.

Getting a Line from a Mixer

The Mixer interface includes variations on the AudioSystem access methods for source and target lines, described above. These Mixer methods include ones that take Line.Info arguments, just as AudioSystem's methods do. However, Mixer also includes these variants, which take no arguments:

Line.Info[] getSourceLineInfo()
Line.Info[] getTargetLineInfo()

These methods return arrays of all the Line.Info objects for the particular mixer. Once you've obtained the arrays, you can iterate over them, calling Mixer's getLine method to obtain each line, followed by Line's open method to reserve use of each line for your program.

Selecting Input and Output Ports

The previous section, regarding how to obtain a line of a desired type, applies to ports as well as other types of lines. You can obtain all of the source (i.e., input) and target (i.e, output) ports by passing a Port.Info object to the AudioSystem (or Mixer) methods getSourceLineInfo and getTargetLineInfo that take a Line.Info argument. You then iterate over the returned array of objects and invoke Mixer's getLine method to get each port.

You can then open each Port by invoking Line's open method. Opening a port means you turn it on—that is, you allow sound to come in or out the port. Similarly, you can close ports that you don't want sound to travel through, because some ports might already be open before you even obtain them. Some platforms leave all ports on by default; or a user or system administrator might have selected certain ports to be on or off, using another application program or operating-system software.

Warning: If you want to select a certain port and make sure that the sound is actually going in or out the port, you can open the port as described. However, this can be considered user-hostile behavior! For example, a user might have the speaker port turned off so as not to disturb her co-workers. She would be rather upset if your program suddenly overrode her wishes and started blaring music. As another example, a user might want to be assured that his computer's microphone is never turned on without his knowledge, to avoid eavesdropping. In general, it is recommended not to open or close ports unless your program is responding to the user's intentions, as expressed through the user interface. Instead, respect the settings that the user or the operating system has already selected.

It isn't necessary to open or close a port before the mixer it's attached to will function correctly. For example, you can start playing back sound into an audio-output mixer, even though all its output ports are closed. The data still flows into the mixer; the playback isn't blocked. The user just won't hear anything. As soon as the user opens an output port, the sound will be audible through that port, starting at whatever point in the media the playback has already reached.

Also, you don't need to access the ports to learn whether the mixer has certain ports. To learn whether a mixer is actually an audio-output mixer, for example, you can invoke getTargetLineInfo to see whether it has output ports. There's no reason to access the ports themselves unless you want to change their settings (such as their open-or-closed state, or the settings of any controls they might have).

Permission to Use Audio Resources

The Java Sound API includes an AudioPermission class that indicates what kinds of access an applet (or an application running with a security manager) can have to the sampled-audio system. Permission to record sound is controlled separately. This permission should be granted with care, to help prevent security risks such as unauthorized eavesdropping. By default, applets and applications are granted permissions as follows:

• An applet running with the applet security manager can play, but not record, audio.
• An application running with no security manager can both play and record audio.
• An application running with the default security manager can play, but not record, audio.

In general, applets are run under the scrutiny of a security manager and aren't permitted to record sound. Applications, on the other hand, don't automatically install a security manager, and are able to record sound. (However, if the default security manager is invoked explicitly for an application, the application isn't permitted to record sound.)

Both applets and applications can record sound even when running with a security manager if they have been granted explicit permission to do so.

If your program doesn't have permission to record (or play) sound, an exception will be thrown when it attempts to open a line. There is nothing you can do about this in your program, other than to catch the exception and report the problem to the user, because permissions can't be changed through the API. (If they could, they would be pointless, because nothing would be secure!) Generally, permissions are set in one or more policy configuration files, which a user or system administrator can edit using a text editor or the Policy Tool program.