Since you have 100 samples played randomly don't bother trying to keep old Players in PREFETCHED or REALIZED states when they've played their content (the first time).

In order to minimize memory...

As noted in my other message, you can't access phone audio via standard J2ME interfaces.

Are we still talking about access to sound in a phone call? That part hasn't changed over the years; the Java application doesn't have access there.

Sound editing in J2ME is limited by the fact that there's no way to cut and concatenate media clips, or to access the media in decoded format, whether they are audio or video. If the editing...

Unless you generate wave files yourself within the application.

EDIT: Of course, that is still not enough to pass the tones to the phone call.

For starters, don't try to map your text events to media time with equals. Instead of "myTimeStamp == mediaTime" use "myTimeStamp <= mediaTime".

Reducing the polling interval of the media time...

As said, HW implementation uses some specific multimedia accelerator or DSP instead of general purpose CPU to perform the media processing. Usually the algorithms for them are implemented by the...

There's nothing wrong with the file itself. The implementation probably reads the whole content during realize or prefetch. If if can't get the EOF properly then that might be the reason for the...

If the sampling rates of the raw PCM are the same then a simple sample by sample addition should do the work. Divide the result by some suitable constant if the addition overflows.

No, you can't.

JSR-234, Advanced Multimedia Supplements (AMMS), gives you tools to get Images on top of the video. AMMS is quite new specification and not available for any products yet.

You...

DataSource is a way to implement your own protocol handler or to create the content on the fly. In order to use it you will implement SourceStreams and DataSource yourself to decocde the content.
...

The InputStream does not have a format of its own. Its the content, for instance MP3 file, in a stream.

Being able to use the same TimeBase for different players and content types is not directly related to mixing. Mixing works, if it works at all, even if you don't set the TimeBase.

The latter. When the recording stops, the media file is generated and becomes available for the application.

Notice that this can vary between different formats and implementations so in theory...

I don't have a 6680 at hand but try what Manager.getSupportedProtocols() returns.

The video data stream can be recorded by RecordControl and then, in theory, you could access the data as it comes out of the system. Unfortunately, the implementations don't give any data out before...

The final version of the specification is now available.

Looks like the device supports only one sound playing at a time. There's no way to get around that restriction.

Unfortunately, the API does not let you do that.

Depending on what you try to do, you could constantly fetch new images by getSnapshot, draw it on screen and then draw on top of that image. Try...

MMAPI 1.1 is binary compatible with MMAPI 1.0. The differences are in the documentation, not in classes or methods.

MMAPI 1.1 mainly enhances the locators you give in createPlayer.

5 images / second is a lot. Even with real digital cameras you won't find that fast image capturing in the mid-priced category.

Forthcoming JSR-234 allows burst capture where at least it is...

With Java you can not currently add metadata to jpeg images.

Other thing came to my mind. You don't try to play more than one player at a time, do you?

How long is the wav file? If it's 20kb it shouldn't last more than 2.5 s. If you transfer the wav file alone to the phone, does it play?

Random.nextInt() does not take a parameter.

Create and prefetch the next Player while the previous is still playing (maybe you do that already).

Other than that, there's nothing to be done if the implementation doesn't support true...