Sound in J2ME

Sound and media are a key feature inmany applications. Games, musicapplications, user interface tones, andalerts are examples of applicationareas that will benefit from the MIDPSound API.
Nội dung trích xuất từ tài liệu:
Sound in J2MESound in J2MESound Khanh LeOverviewOverview 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 APIMIDP 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 supportMobile Media APIMobile 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.ApplicationsApplications 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.MIDP Sound Architecture The framework of sound and media support in MIDP 2.0 consists of three main components: Manager, Player, and Controls.MIDP Sound Architecture 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— for example, VolumeControl—to control volume.Player Creation andManagementManagement Property queries: The MIDP sound API provides a mechanism for querying the type of content and protocols that the device supports. The property queries are enabled by the methods Manager.getSupportedContentTypes and Manager.getSupportedProtocols. Creating Players for Media Data: The Player interface controls the rendering of time-based media data. It provides the methods to manage the life cycle of the Player, controls the playback progress, and obtains the presentation components. A Player can be created using one of the two createPlayer methods of the Manager class: // Create a Player to play back media from an InputStream createPlayer(java.io.InputStream stream, String type) // Create a Player from an input locator createPlayer(String locator)Data Source for MediaData Content types identify the type of media data for Player objects when the Player is created using an InputStream. For example, here are a few common content types: Tone sequences: audio/x-tone-seq  Wave audio files: audio/x-wav  AU audio files: audio/basic  MP3 audio files: audio/mpeg  MIDI files: audio/midi MIDP Sound API Player statediagramPlayer life cycle Typically, a Player moves from the UNREALIZED state to the REALIZED state, then to the PREFETCHED state, and finally on to the STARTED state. A Player stops when it reaches the end of media or when the stop method is invoked. When that happens, the Player moves from the STARTED state back to the PREFETCHED state. Upon calling the Player.stop method, the playback position in the file does not change, so calling Player.start again will continue the playback from the same location. The basic use of a Player only requires the Player.start and Player.stop methods. However, in order to fully utilize all the functionality of the Player, parameters must be set up appropriately to manage the life-cycle states, and the state transition methods should be used correctly to advan ...