Sound, Music, and Video: MMAPI - Beginning J2ME: From Novice to Professional - page 310

The next state, PREFETCHED , means the Player has done everything else it needed to do to
get ready to start rendering audio. This might include obtaining control of the audio hardware,
filling up buffers, or other operations.
When the Player has begun rendering audio data, it is in the STARTED state.
One final state, CLOSED , indicates that the Player has released all resources, shut down all
network connections, and cannot be used again.
Player contains a corresponding set of methods that move from state to state:

public void prefetch()
public void realize()
public void start()

These methods work as you'd expect, for the most part. If you skip a step, the intervening
states are implied. In the preceding example, we call start() on a freshly created Player , which
implies calls to prefetch() and realize() .
If anything goes wrong with locating the media data or acquiring system resources, these
methods throw a MediaException .
Several other methods allow for backward state transitions, although their names are not
as intuitive. The stop() method takes a STARTED Player back to PREFETCHED . The deallocate()
method moves a PREFETCHED or STARTED Player back to the REALIZED state by releasing resources.
The deallocate() method has one additional wrinkle; it will take an UNREALIZED Player that is
stuck trying to locate its media (in the middle of realize() ) back to the UNREALIZED state.
Finally, the close() method moves a Player in any state to CLOSED . All resources are
released, all network connections are closed, and the Player cannot be used again.
You may retrieve the Player 's current state by calling getState() .
Now that you understand Player 's life cycle, you can probably imagine ways to improve
on the simple AudioMIDlet presented previously. You might, for example, call prefetch() on
the newly created Player to ensure that playback could begin as soon as possible after the user
selects the Play command. You might not have noticed much of delay, but a real device will
perform much slower:

• Your desktop computer running the emulator has a lot more processing power and

memory than a MIDP device.

• The emulator on your desktop probably has a much faster network connection than a

real MIDP device.

The file relax.wav that is used by AudioMIDlet is very small (1530 bytes). A larger media
file would produce more noticeable delays.

•

As with network and persistent storage operations, any time-consuming operations with a
Player should be performed in a thread that is separate from the user interface thread. Although
the start() method does not block, both realize() and prefetch() will not return until they
have finished their potentially slow work.

Controlling Players
A Player 's media time is its current position in the audio playback. For example, a Player that
is halfway through a 4-second audio clip would have a media time of 2,000,000 microseconds.