Development with the MMAPI on the 6600
MMAPI and Mickey Mouse
The Multi Media Application Programming Interface or the MMAPI is one of the most interesting features of this phone. The presence of Mickey Mouse is perhaps the most frustrating thing about the phone, you will run into him very quickly.
The MMAPI Documentation suggest the following approach for capturing voice input from the microphone:
Player p= Manager.createPlayer("capture://audio");
When you play back what you recorded, you will hear what sounds like an old chip monks recording instead of your own voice. That's because for some reason the default PCM format does not seem to work on this phone. This is called the 'Mickey Mouse' effect in some forums. Nokia has used the same name in their known issues document.
The suggested work around is to createcreate your player as follows:
These examples will not work on the SDK but will execute on the phone. The code does compile with out error, but it does not run on the emulator. When you do load up your midlet on the phone you will find the chip monks and mickey are still hanging around your phone.
Perhaps a firmware update might make the above examples work for your. Instead of going to all that trouble, if you create your player as follows you will hear your own voice when you play back.
Player p= Manager.createPlayer("capture://audio?encoding=amr");
This player uses the Advanced Multi Rate format. Unfortunately the AMR format causes more headaches if you are planning to play back these files on your pc. Many sound players for the desktop still do not support for the AMR format. If you think that's bad, like the other settings in the previous sample, AMR capture is not supported at all on the Wireless Toolkit.
Saving the Captured Data
The most common method of saving data on java phones is to save it on the record store, this is infact one of the recommended ways for saving captured audio data. Unfortunately the maximum record size in the 6600 seems to be restriced to 128kb. After all the overheads your recording is limited to just 132532 bytes. With the wave format this leaves room for only a few seconds of audio capture. Everything else is truncated.
If you use the AMR format as discussed above, you may be able to make a longer recording because it is highly efficient when it comes to storage space. The PCM format takes up much for space. Since the available storage space is limited normally you change your WTK settings to match the capacity of the device. That does not work with audio capture since we are forced to work with different encoding when switching between the WTK and phone. You have to keep your fingers crossed that the storage space will not be exceeded.
Video capture on the 6600 is just a cosmetic. You can only use the VideoControl to display the lightwaves that fall on the lense on the phones display. That's right recording is not supported. If you try to retrieve a RecordControl instance you get a null.
The capture image feature seems to work but what good is it since you can only save the image captured to the RMS (only upto 128 kb) at that.
I read quite a few posts from developers who had not been able to make the MMAPI demo included with the sun WTK to work for them on the 6600. I also ran into this problem. I found that some of these problems were because the demo attempts to save the recordings on the filesystem (The Connector does not provide access to the file system). If you modify the samples to save to the RMS instead they will work fine.
Some of the other midlets require internet connectivity so you need to make sure that your phone is correctly configured for GPRS access. In some cases though the code needs more drastic changes because it attempts to make use of varius controls that are not implemented on the phone. In other words the MMAPI implementation on the 6600 cannot really be considered as complete.
On a final note the phone freezed more than once when working with sound and video.