Programming Wireless Devices with the Java2 Platform

13.1 Overview of the MIDP 2.0 Sound API

13.1.1 MIDP Media Support

MIDP devices range from low-end mass-market phones with basic sound support to high-end media phones with advanced audio and video rendering capabilities. To accommodate these diverse configurations and multimedia processing capabilities, an API with a high level of abstraction and support for optional features is needed. The central goal of the specification work for the Sound API was to address the wide range of application areas. As a result, two API sets were developed:

• MIDP 2.0 Sound API

• Mobile Media API (MMAPI)

The division into two interoperable API sets arose from the fact that some devices are very resource-constrained. It may not be feasible to support a full range of multimedia types, such as video, on some mobile phones. As a result, not all MIDP 2.0 target devices are required to support the full generality of the Mobile Media API, such as the ability to support custom protocols and content types.

MIDP Sound API

The MIDP 2.0 Sound API is intended for resource-constrained devices such as mass-market mobile phones. The basic level of sound support mandated for all devices is the presence of monophonic buzzer tones. This API is a directly compatible subset of the full Mobile Media API. Furthermore, due to its building block nature, this subset API can be adopted to other J2ME profiles that require sound support.

Mobile Media API

The full Mobile Media API is intended for J2ME devices with advanced sound and multimedia capabilities. The target devices for the Mobile Media API include powerful mobile phones, as well as PDAs and set-top boxes.

Applications

Sound and media are a key feature in many applications. Games, music applications, user interface tones, and alerts are examples of application areas that will benefit from the MIDP Sound API.

In the following sections, the MIDP Sound API is discussed in more detail. In Section 13.4, "Enhanced Media Support Using the Mobile Media API," a more detailed look at the MMAPI is provided.

13.1.2 Design Goals

The main design goals for the MIDP Sound API were:

• Playback of time-based audio and ringing tones. This is the main feature of the sound API. The basic target of the design is to let applications play back media in various formats.

• Independence of specific media formats and protocols. The sound API itself is not targeted to support any specific media format or protocol. There are no hard-coded format descriptors in the API. Rather, the formats are handled as MIME types. This provides extensibility and support for future formats. However, in MIDP Specification version 2.0, a set of mandatory protocols and content formats for audio have been defined to ensure interoperability.

• Support for tone generation. There is an internal tone sequence format and a method to play single tones. An internal tone sequence format has been added to the API in order to let MIDP applications create simple monophonic tone sequences on their own.

13.1.3 Requirements

The design goals stated in the previous section form a set of requirements, which have to be fulfilled by all devices implementing the sound API. The requirements that were defined in MIDP Specification version 2.0 include

• low footprint audio playback,

• protocol and content format independence,

• support for tone generation,

• support for general media flow controls (start, stop, etc.),

• support for media-specific type controls (such as volume control), and

• support for capability queries.

This subset differs from the full Mobile Media API requirements in the following ways:

• The MIDP 2.0 sound API is audio-only. It excludes all Control classes that are specific to MIDI, video, or graphics.

• The sound API does not support custom protocols (via custom DataSource classes).

Scalability

It is important to note that the building block subset used in MIDP 2.0 is a proper subset of the full Mobile Media API (MMAPI), and it is fully forward-compatible with the MMAPI. In order to add the full Mobile Media API functionality to a MIDP 2.0 device, one only needs to implement the additional classes and methods from that API.

Formats and protocols

In the context of sound and multimedia processing, protocol handling refers to reading data from a source (such as a file or streaming server) into a media processing system. Content handling usually requires processing the media data (parsing or decoding, for example) and rendering the media to output devices such as a loudspeaker. The MIDP 2.0 sound API is defined in a manner that enables the custom formats and protocols. At the very minimum, the devices must be able to play tones, either via dedicated hardware or via software algorithm. Furthermore, MIDP 2.0 devices

• must support tone generation in the media package,

• must support 8-bit, 8 KHz, mono linear PCM wav format if any sampled sound support is provided,

• may include support for additional sampled sound formats,

• must support Scalable Polyphony MIDI (SP-MIDI) and SP-MIDI Device 5-to-24 Note Profile if any synthetic sound support is provided, and

• may include support for additional MIDI formats.

In other words, the basic requirement for sound support for all mobile information devices is monophonic tone sequencing. Both synthetic audio (MIDI) and sampled audio are optional, and these features may be implemented if the device provides corresponding hardware or software support.

The audio content used by MIDlets normally originates in a MIDP 2.0 implementation from three different sources: 1) over-the-air via HTTP 1.1 protocol, 2) via the Record Management System (RMS), or 3) from a JAR file. It should be noted that whereas the sound API supports a generic protocol naming mechanism, MIDP 2.0 only supports HTTP 1.1. With the use of the full Mobile Media API, custom protocols for media streaming can be introduced.

13.1.4 MIDP Sound Architecture

The MIDP sound architecture design was based on a set of design goals and requirements agreed to by the MIDP 2.0 expert group. A baseline for sound support that all devices must follow was created. Optional features may be supported, but they are not mandated by the MIDP Specification.

The framework of sound and media support in MIDP 2.0 consists of three main components: Manager, Player, and Controls. Figure 13.1 shows an overview of the architecture. A simple way to understand the functionality of the Sound API is to think of the functionality of an ordinary video player (VCR). Class Manager represents the VCR user who loads the tape into the VCR and controls the overall use. The technical functionalities of the VCR, such as playing, stopping, rewinding, or recording, are represented by the Player class. Finally, the Control classes define the actions that determine how the VCR is controlled, for example, by adjusting the volume or by initiating the recording mode.

In more technical terms, the functionality of the sound architecture can be described as follows. Class Manager is the access point for obtaining system-dependent resources such as Player objects for multimedia processing. Applications use the Manager class to request Players and to query supported content types and supported protocols. The Manager class also includes a method to play simple tones.

A Player is an object that is used to control and render media that is specific to the content type of the data. The application may obtain a Player by giving a locator string or an InputStream and a content type to the Manager class.

A Control is an interface that is used to implement all of the different controls a Player might have. An application can query a Player to check which controls it supports and then ask for a specific Control梖or example, VolumeControl梩o control volume.