Using audio session properties, you can optimize your application’s audio behavior for device hardware at runtime. This lets your code adapt to the characteristics of the device it’s running on, as well as to changes made by the user (such as plugging in a headset or docking the device) as your application runs.
The audio session property mechanism lets you:
Specify preferred hardware settings for sample rate and I/O buffer duration
Query many hardware characteristics, among them input and output latency, input and output channel count, hardware sample rate, hardware volume setting, and whether audio input is available
Write callback functions to respond to property value change events
The most commonly used property value change event is route changes, covered in the previous chapter. You can also write callbacks to listen for changes in hardware output volume and—to support devices that don’t have a built-in microphone—changes in the availability of audio input.
The audio session APIs let you specify preferred hardware sample rate and preferred hardware I/O buffer duration. Table 5-1 describes benefits and costs to consider when specifying such preferences.
Setting | Preferred sample rate | Preferred I/O buffer duration |
|---|---|---|
High value | Example: 44.1 kHz + High audio quality – Large file size | Example: 500 mS + Less-frequent disk access – Longer latency |
Low value | Example: 8 kHz + Small file size – Low audio quality | Example: 5 mS + Low latency – Frequent disk access |
For example, as shown in the top-middle cell of the table, you might specify a preference for a high sample rate if audio quality is very important in your application, and if large file size is not a significant issue.
The default audio I/O buffer duration (about 0.02 seconds for 44.1 kHz audio) is appropriate for most applications. It provides enough responsiveness for any sort of user interaction, including fast-action games. Do not set a lower I/O duration unless your application needs it, such as for voice over IP (VOIP).
To set hardware preferences, use the AudioSessionSetProperty function along with the kAudioSessionProperty_PreferredHardwareSampleRate and kAudioSessionProperty_PreferredHardwareIOBufferDuration property identifiers. For a code example, see “Specifying Preferred Hardware I/O Buffer Duration.”
Important: Although you can safely specify hardware preferences at any time after the audio session is initialized, best practice is to do so while the session is inactive. After you establish hardware preferences, activate the audio session and then query it to obtain the actual values. This final step is important because the system may not be able to provide what you ask for.
Your application’s audio session can tell you about many hardware characteristics of a device. These characteristics can change at runtime. For instance, input sample rate may change when a user plugs in a headset. Callbacks are available for some of these characteristics. For the others, query their values directly.
Important: To obtain meaningful values for hardware characteristics, ensure that the audio session is initialized and active before you issue queries.
Some of the most useful audio session hardware properties are shown in Table 5-2.
Audio session property | Description |
|---|---|
| The hardware sample rate of the device. Use this property when setting up an audio recording format (see “Obtaining and Using the Hardware Sample Rate”). No callback invocation is available for this property. |
| The playback volume of the device. |
| The playback latency of the device. No callback invocation is available for this property. |
| Whether audio input is available on the device. Use this property to determine if audio recording is possible. For a code example, see “Determining Whether a Device Supports Recording.” |
The full list of audio session properties is described in Audio Session Services Reference, in the Audio Session Services Property Identifiers enumeration.
The previous chapter, “Handling Audio Hardware Route Changes,” went into depth on responding to one particular property value change event—the audio hardware route change. The “Audio Session Cookbook” chapter includes a complete example, “Responding to Audio Hardware Route Changes.” You can use the same function callback technique to respond to other events, notably:
Changes made by the user to the hardware playback volume
Changes to the availability of audio input—meaning the addition or removal of a microphone on devices, such as the iPod touch (2nd generation), that support recording but only when a headset is attached
To respond to playback volume changes, write a property listener callback function that listens for the kAudioSessionProperty_CurrentHardwareOutputVolume property. For changes to the availability of audio input, listen for changes to the kAudioSessionProperty_AudioInputAvailable property.
Last updated: 2010-07-09