Just curious about the general specs for audio. Like, what audio file format? Size/Length limitations?
I'm sure j2me is fragmented into many platforms, but ust trying to get a grasp. After hearing all the news with Whats App, it made me realize that j2me is still important.
I am hoping to compile a helpful article regarding j2me standards and practices for mobile games
The MMAPI (JSR 135) (used in MIDP1.0) and the Player classes of MIDP2.0 supports playback of Standard MIDI Format and Adaptable Multi-Rate Wideband (AMR) files.
Most J2ME enabled phones nowadays also support playback of MP3 and WAV files.
The typical way of doing audio for a game, is to either
use MIDI file(s) for music and AMR files for sound effects, both playing at the same time, or
use MIDI file(s) for both music and sound effects, where only one can play at a time.
In the beginning, phones could typically only handle 1 Player object at a time. As a result, you had to make the user select whether he wanted music or sound effects.
Later on, 2 simultaneous Player objects became possible, but only if they handled 2 different formats. You couldn't (and still can't) play two MIDI files at the same time.
Even today there are only very few phones that supports more than 2 simultaneous Player objects.
A lot of phones also supports the brilliant Mobile eXtensible Music File Format (XMF/mXMF) - but only some of them does it correctly. XMF basically consists of a MIDI file + a sound-font. Meaning, it allows you to provide your own instruments for your MIDI file. For one thing this means that your music will (finally) sound the same on all devices.
Another interesting use for this was to provide a sound-font containing multiple sound effects, and that way have something similar to the SoundPool you can have with Android.
I've done extensive testing with the XMF format, and sadly found that the XMF format is poorly supported. Only Symbian devices seems to support it well. Sony Ericsson feature phones are very buggy and limited when it comes to XMF playback (will only play XMF files containing a sound-font less than 30kb - and even then it sometimes just crashes). And other brands seems to not support it at all, so sadly I have to recommend that you avoid the format.
As a musician I was rather annoyed by that, because it could really have given the J2ME platform some awesomeness regarding audio.
There's been experiments in the past regarding playback of MODules (MOD/XM/S3M/IT files). I won't go into details, but just say that it's not the way to go. Almost no phones can handle it.
On newer J2ME enabled phones you can get away with using MP3 for music nowadays. But it does take up memory of course. So in order to support as many devices as possible, the best practise is to use MIDI for music and AMR files for sound effects.
You can e.g. create your music Player first, and then in a try/catch block load a sound effect. If it fails, it'll just be null. So you check if the sound effect object is null before starting playback.
Next comes the various tips'n'tricks for getting your audio to play on as many devices as possible.
I have written some guidelines about that here:
http://www.indiegamemusic.com/help.php?id=1
IndieGameMusic.com also contains several MIDI files optimized for J2ME. Stripped unnecessary data, keeping polyphony down, filesize to a minimum. Some tracks even available in multiple formats, like MIDI for J2ME, XM for Android/iPhone, MP3/OGG for other, so developers can support multiple platforms, having their game contain the same track.
Related
I'm looking for a simple-ish library for outputting audio. I'd like it to meet these criteria:
Licensed under LPGL/zlib/MIT or something similar – i'm going to use it in an indie commercial application and i don't have the money for a license.
Written in C, but C++ is fine.
Cross-platform (Windows, Linux, maybe OSX)
Able to read from some sort of audio file (i'd prefer WAV or OGG but i will gladly use less popular formats if need be) in memory (i've seen the use of a memfile struct and user-defined I/O callbacks). I need the file to be in memory because i put all my resources into a .zip archive, and i use another library to load those archived files into memory.
Supports playing multiple sounds at the same time, having a max of 8 or so is ok.
I'd really like to either have the source code or a static library (MinGW/GCC lib???.a), but if nothing else is available i will use a shared library.
I must have come accross two dozen different audio libraries in my search, all of which haven't quite met these criteria...
I would recommend PortAudio + libsndfile. Very popular combo, meets your requirements. Used by many other software applications including audacity.
Some of the candidates that immediately spring to my mind are:
SDL (there is a tutorial that demonstrates how to play a .wav format sound)
libav
ffmpeg
libao
OpenAL Soft
Jack Audio
You may have already looked at these and eliminated them, though. Can you give some more detail about the libraries that you have eliminated from consideration and why? This will help narrow down our recommendations.
You might want to look into SDL and SDL_mixer. Here is a good tutorial.
I've used SDL_mixer and it makes it easy to play background sounds or music and play multiple simultaneous sounds without having a need to write your own sound sample mixer.
I ended up using PortAudio (very low-level, flexible license) and wrote a mixer myself. See this topic i made on the C++ forums for some other people's tips on writing a custom mixer. It's not hard at all, really; i'm surprised that there are so many mixer libraries out there. For a breakdown of the WAV format (ready-to-stream raw audio data with a 44-byte header) see this.
I'm looking for advice on how to generate videos in C. The main issues I'll be dealing with are
Must be open source, would prefer BSD type license but GPL is acceptable
Must be reasonably well documented (I'm looking at you FFMPEG)
Must be able to generate a non-compressed video
Must be able to draw each frame
Should be able to set the frame rate (though of course I can just make n identical frames)
My toolkit is the GNU development system on UNIX like systems (Linux, OS X, Cygwin, ...)
Having said that, I'm picky about these requirements because if I don't have them I know I can pretty easily generate the individual frames with libgd and use ffmpeg commands to output a video. The point is that I'd rather be able to draw them and generate the video entirely in my C code. Even better would be to be able to provide the library in my own source (BSD license) so that my users don't need to worry about getting things installed on their particular platform.
I'm not set on a video codec other than the availability of non-compressed video (I'm visualizing changes in simulated rotational spectroscopy as rotational parameters or other variables like temperature change). Advice on a particular codec welcome.
can anyone guide me the steps and knowledge needed to port a codec in ARM board. Like a development board below
http://www.arm9board.net/sel/prddetail.aspx?id=348&pid=200&AspxAutoDetectCookieSupport=1
i want to gain expertise in audio and video codec for embedded systems. My experience level is novice but i am ready to learn.
Need the pointers to start with
If you are looking to run on linux for example then there really is nothing to it, just compile as if you were running on a desktop/server. You might have performance issues, but those can and have been worked through in many ways.
If you are looking to go embedded, there are a lot more resources out there now than when I tried to do exactly what you are trying. In particular open source fixed point solutions. With arm becoming the leading processor in the world and most of them being fixed point this was solved many times over so there is plenty of code out there to play with.
That is a nice board you have found, on initial glance I didnt see if their core has a fpu or not, for that core it is optional. Just from the advertising I would assume out of the box that board/package does video and audio and all you need to do is turn it on and copy your videos our audio files over and play them.
If you want to learn the nuts and bolts of the codecs, then purchase the specs from ISO/IEC, probably a hundred to two hundred bucks each. And refresh your calculus, there is a lot of it.
Try to look at this project: http://embdev.net/articles/ARM_MP3/AAC_Player It's a MP3/AAC player based on AT91SAM7S256 microcontroller.
Check also this https://datatype.helixcommunity.org/Mp3dec decoder. It's optimized for ARM.
Both has bindings for C, both can play various formats.
Which one is more superior? in terms of simplicity, performance, overhead and memory footprint.
Also which one is better at handling multiple streams?
I have not programmed with either of those, but I believe that OpenAL has been designed to render and output multiple-channel audio for games, with real-time performance as a requirement.
libSoX is more for input and output from audio files, as well as for format conversions. There are lots of plugins but AFAIK it has not been designed for real-time audio output. It seems significantly simpler to use, though.
You might also want to have a look at libsndfile.
What exactly is it that you want to do?
While I have never used OpenAL, I've heard a lot of bad things about it that make it sound unprofessional and basically a dead end. From Wikipedia:
OpenAL was originally developed by Loki Software in order to help them in their business of porting Windows games to Linux. After the demise of Loki, the project was maintained for a time by the free software/open source community, and implemented on NVIDIA nForce sound cards and motherboards. It is now hosted (and largely developed) by Creative Technology with on-going support from Apple, Blue Ripple Sound, and free software/open source enthusiasts.
While the OpenAL charter says that there will be an "Architecture Review Board" (ARB) modeled on the OpenGL ARB, no such organization has ever been formed and the OpenAL specification is generally handled and discussed via email on its public mailing list.
Since 1.1, the implementation by Creative has turned proprietary, with the last releases in free licenses still accessible through the project's subversion. However, OpenAL Soft is a widespread Open Source alternative.
There was also an issue with it messing up the state of the calling application; I believe just linking it caused some global constructors to run before the invocation of main in a way that altered the program's initial environment, and broke some programs (MPlayer perhaps?). It's unclear to me whether this issue was ever fixed, but it screams bad library and I would be skeptical of ever trusting a library historically contained such abuses.
I'm working on an audio application, written in C. I need to provide live audio playback under Windows. I need to decide which audio API to use. I'm planning to use the basic waveOut API, but I wanted to check to see what the community here recommends.
I want code that will Just Work on any recent version of Windows, with no need to install libraries; and I want minimal latency.
I don't need or want any "effects", I just need to faithfully play whatever wave samples the application generates.
My understanding is that most of the professional audio applications on Windows use ASIO, which gives excellent low latency, but I don't want ASIO because I want my code to Just Work and most people don't have ASIO pre-installed on their computers. (At a later date I may go back and also add ASIO as an option, but I'm going for the most general solution first.)
Is there anything out there that would be better than waveOut for my purposes, or is that the best choice?
It depends on what you are trying to do. The basic waveOut audio API is better for streaming audio. It lets you queue up several buffers and have them automatically played in succession. But if audio is playing and you want to change it, or add something to it, that's relatively hard.
DirectX audio is better for event based audio. You can have several things playing at the same time without having to do the mixing yourself. You can add or remove little pieces of audio easily - like playing a sound when the user pulls the trigger on their gun. But streaming (i.e. playing 1 buffer after another) is harder.
waveOut is designed to facilitate playing audio that is constant, like a .mp3 file. DirectX is designed for audio that is intermittent, like feedback in a game.
ASIO is like the worst of waveOut and DirectX in terms of difficulty of programming, and it's not that stable. Applications typically can't share the audio device. However, it gives you the lowest latency access to that audio hardware. ASIO also gives you a way to synchronize playback on multiple devices.
If you don't need to be able to change what is going to be played right before it is played, and you don't need to synchronize multiple devices, then you don't need ASIO.
in addition to the options mentioned by John Knoeller, there is WASAPI which allows for much lower latencies than WaveOut, but unfortunately is only available from Windows Vista onwards.
At the time I asked this question, I wrote streaming code using the waveOut and waveIn APIs. Since then, I have discovered a useful library:
PortAudio
http://www.portaudio.com/
PortAudio is free software with a commercial-friendly license. If you write your code to call PortAudio it should be able to work with waveOut devices but also with ASIO devices under Windows; it can be then recompiled for Linux and should work with ALSA devices; and it can then be recompiled for the Mac and should work with CoreAudio devices. I haven't tested the Mac part but my project is working great with Windows and Linux.
Having written a DirectSound streaming application myself, I certainly recommend it for low-latency and ease of use. Also, it enables you to set a higher quality format for playback on legacy editions of Windows.