Mobile Media API

Mobile Media API (MMAPI, JSR-135) - a set of classes for J2ME , which allows you to play sound and video; part of MIDP 2.0.

Content

Purpose

A uniform way to play all types of sound and video, regardless of whether they are in a file or downloaded via the Internet .
Delays resulting from downloading files and bringing the phone to the desired state are under the control of the programmer.

Supported Formats

MIDP 2.0 requires the phone to play tonal sounds and WAV sounds. Playing other formats ( MIDI , MP3 , AMR , 3GP , MPEG -4, MMF , iMelody ) is optional. However, MIDI is de facto played on all phones.

Most Important Classes

MMAPI classes are in the javax.microedition.media package.

The Manager class is used to create players. All players have a Player interface. There are other classes and interfaces in the MMAPI that serve to control volume, respond to events, etc.

Five player states

The player has five states:

UNREALIZED (just created);
REALIZED (downloaded);
PREFETCHED (ready to play);
STARTED (in playback state);
CLOSED (player no longer needed).

The player just created by the Manager.createPlayer() function is in the UNREALIZED state.

The realize() function loads all the resources needed to play, with the exception of “valuable and scarce” (in particular, it reads a file or communicates with the server ). The player is transferred from the UNREALIZED state to the REALIZED state. Calling the realize() function may take some time.

The prefetch() function loads “valuable and scarce resources”; the player changes from UNREALIZED or REALIZED to PREFETCHED . Calling the prefetch() function may also take some time. In most MMAPI implementations, only one player can be in the PREFETCHED state.

The start() function starts playback, moving the player from the UNREALIZED , REALIZED or PREFETCHED states to the STARTED state. If the player was in PREFETCHED state, the start() function is guaranteed to be called instantly. If the player is rewound to the end, the start() function starts playback from the beginning.

The close() function is called when the player is no longer needed. The player enters the CLOSED state, and in this state the garbage collector can destroy it.

To stop the player, the stop() function is called. In this case, it switches from the STARTED state to the PREFETCHED state (and does not rewind anywhere).

To release scarce resources, the deallocate() function deallocate() called. In this case, it switches from the STARTED or PREFETCHED state to the REALIZED state.

The deallocate() function has another important role. If the player does not complete the REALIZED state (that is, the file is not fully downloaded), the file is interrupted and the player remains in the UNREALIZED state.

There is UNREALIZED path to the UNREALIZED state.

Control Interface

The empty Control interface serves as the basis for the construction of various playback control interfaces. Several Control descendants are defined in the javax.microedition.media.control package: ToneControl , VolumeControl , MIDIControl , etc.

The simplest code example

  import javax.microedition.media. * ;
 
  Player p = Manager .  createPlayer ( "http://www.fishy.com/my.mp3" , "audio / mp3" );
  p .  start ();

Phones Supporting MMAPI

MMAPI is part of MIDP 2.0. That is, any phone that supports MIDP 2.0 is required to support MMAPI. Here is a (non-exhaustive) list of phones with MIDP 1.0 that support MMAPI.

Nokia

All Series 60 phones except the 7650 and Siemens SX1 .

Sony Ericsson

All models with J2ME support.

Siemens

All models with a 101 × 80 screen ( M55 , S55 , etc.) have their own set of classes for playing multimedia, similar to MMAPI.

Problems

MMAPI is designed to play sound, video, etc. in multimedia applications . For example, on a Motorola E398 phone, the built-in audio player is written in Java using MMAPI. However, MMAPI is not suitable for implementing sound effects in mobile games , since each phone has its own subtleties. Some allow you to keep all sounds simultaneously in PREFETCHED state and play them at any time; in others you have to resort to various tricks. There are less obvious subtleties. It happens that between the stop and replay of the player some time should pass, on some by no means obsolete models this time is 1-2 seconds!

Some "subtleties" are in fact direct violations of the standard.

Most Common Standard Violations

By standard, if the player is in the UNREALIZED state, the start() command will first translate it to REALIZED , then to PREFETCHED , then to STARTED . Some phones do not allow such "jumping"; it is required to set explicitly realize() , prefetch() , start() .

Some phones upload files deferred, which is also against the standard. Suppose a player is created and set to PREFETCHED . By standard, the start() command should be called instantly. But some MMAPI implementations load only with the start() command (and only repeated start() actually called instantly).

According to the standard, if playback has ended, then after the start() command is repeated, the player should start playback from the beginning. On some phones, such a player does not play anything until it is explicitly rewound with the setMediaTime(0) function.

Waiting for MIDP 3.0

It is assumed that the not yet released MIDP 3.0 will solve this discrepancy by tightening the requirements for the implementation of MMAPI.