Sound in J2ME

Chia sẻ: Quang Tuyen | Ngày: | Loại File: PPT | Số trang:23

lượt xem

Sound in J2ME

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

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.

Chủ đề:

Nội dung Text: Sound in J2ME

  1. Sound in J2ME Sound Khanh Le
  2. Overview Overview 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.
  3. MIDP Sound API MIDP 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
  4. Mobile Media API Mobile 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.
  5. Applications 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.
  6. MIDP Sound Architecture The framework of sound and media support in  MIDP 2.0 consists of three main components: Manager, Player, and Controls.
  7. 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.
  8. Player Creation and Management Management 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( stream, String type) // Create a Player from an input locator createPlayer(String locator)
  9. Data Source for Media Data 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 
  10. MIDP Sound API Player state diagram
  11. Player 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 advance between the various Player states. Additional Player functionalities include looping of audio using the  setLoopCount method, and obtaining or setting the current position of media playback using the getMediaTime and setMediaTime methods. Furthermore, the getDuration method can be used to query the length of the media file.
  12. PlayerListener Class PlayerListener defines an interface that can  be used for receiving asynchronous events generated by Player objects. Applications can implement this interface and register their implementations with the addPlayerListener method of class Player. A number of standard Player events are defined in  the PlayerListener interface. Event types are defined as Strings in order to support extensibility because different implementations may introduce proprietary events by adding new event types.
  13. Tone Generation The minimal requirement for all MIDP 2.0 devices is to support  the playback of monophonic single tones. In its simplest form, tone generation is implemented as a  single buzzer or simple monophonic tone generation. This feature is enabled by two different methods in the MIDP 2.0 API. The first possibility is to use the Manager class, which provides a  method for playing back simple tones, specified by a note and its duration. A note is given in the range of 0 to 127 inclusive. The frequency of the note can be calculated using the following formula: SEMITONE_CONST = 17.31234049066755 = 1/(ln(2^(1/12))) note = ln(freq/8.176)*SEMITONE_CONST // The musical note A = MIDI note 69 (0x45) = 440 Hz. The second possibility to create sequences of single tones is to  use the ToneControl API
  14. Sample Code Example: Single tone generation  try { Manager.playTone(ToneControl.C4 /* note */, 5000 /* duration in ms */, 100 /* max vol */); } catch (MediaException e) { } Example: Creating a player from media stored in JAR  try { InputStream is = getClass().getResourceAsStream("music.wav"); Player p = Manager.createPlayer(is, "audio/X-wav"); p.start(); } catch (IOException ioe) { } catch (MediaException me) { } Example: Creating a player from media in HTTP locator  try { Player p = Manager.createPlayer("http://webserver/music.mid"); p.start(); } catch (IOException ioe) { } catch (MediaException me) { }
  15. Media Controls Control objects are used for controlling content-type-specific  media processing operations. Control object provides a logical grouping of media-processing functions. All Control classes implement the interface Controllable, and  the Player interface is a subinterface of Controllable. For example, a Player can expose a VolumeControl to allow the volume level to be set. The package specifies a set  of predefined Controls classes. In MIDP 2.0, two controls are specified and required: ToneControl and VolumeControl. The Controllable interface provides a mechanism for obtaining  the Controls from an object such as a Player. It provides methods to get all the supported Controls and to obtain a particular Control based on its class name.
  16. ToneControl ToneControl is an interface that enables the  playback of a user-defined monotonic tone sequence. A tone sequence is specified as a list of tone  duration pairs and user-defined sequence blocks. The list is packaged as an array of bytes. The setSequence method is used for defining the sequence for the ToneControl
  17. VolumeControl VolumeControl is an interface for manipulating the audio  volume of a Player object. The volume settings interface allows the output volume to be  specified using an integer value that varies between 0 and 100. The mapping for producing a linear multiplicative value is  implementation-dependent. Setting mute on or off does not change the volume level  returned by method getLevel. If mute is true, no audio signal is produced by the Player; if  mute is false, an audio signal is produced and the volume is restored. When the state of the VolumeControl changes, a  VOLUME_CHANGED event is delivered to the Player through its PlayerListener.
  18. Sample Code Sample The sample application below defines a simple  media player for sampled audio with an attached volume control. The Player is created from an InputStream.  A Gauge is used for visualizing and controlling the  volume of the player. Simple player functions including start, stop, and  rewind are supported. Furthermore, PlayerListener events are defined for  printing the player states during the execution of the program.
  19. Enhanced Media Support Using the Mobile Media API As discussed earlier in this chapter, MIDP Sound  API is a subset of the Mobile Media API (MMAPI) defined by the Java Community Process effort JSR 135. MMAPI includes a lot of additional functionality that  is not present in the MIDP 2.0 Sound API. The additional features introduced by the Mobile  Media API include the following: Custom protocols through the DataSource  Synchronization of multiple Players using the TimeBase  interface Interactive synthetic audio  Video and camera functionality  Capture and recording  Metadata 
  20. DataSource Class DataSource encapsulates  protocol handling. It hides the details of how the data is read from its source, and whether the data is coming from a file, streaming server, or a proprietary delivery mechanism. Class DataSource provides a set of methods to allow a Player to read data.
Đồng bộ tài khoản