OpenSL ES for Android

I'm beginning to feel like an AD&D half-elf multi-class 3rd level character. All of my classes are level 1 or 2, and I've got like 7 classes... If you don't know what I mean, I'm not going to explain. (It's actually kinda cool in a way: It keeps things interesting.) Here's another one!

Time to become a sound guy!

**Think of this API (Application Programming Interface) as a huge soundboard in a recording studio. The computer screen is a window into the recording booth. The keywords and classes are buttons, dials, sliders and groups of all of the above situated on the interface/soundboard.

While learning the NDK for Android SDK, I am focusing on OpenSL ES for Android. Sound baby. I'll throw some notes up here. I'm not promising any organization and/or coherency.

This first link is titled, "OpenSL ES for Android". It refers specifically to using OpenSL ES within Android 2.3, the implementations and limitations thereof and other important knowledge and warnings.
http://mobilepearls.com/labs/native-android-api/opensles/index.html

{
Some extracted notes on the above link:

...Compiled and linked inline

You can link your audio content directly into the shared library, and then play it using an audio player with buffer queue data locator. This is most suitable for short PCM format clips. The example code uses this technique for the "Hello" and "Android" clips. The PCM data was converted to hex strings using a bin2c tool (not supplied).

...The PCM data format can be used with buffer queues only. Supported PCM playback configurations are 8-bit unsigned or 16-bit signed, mono or stereo, little endian byte ordering, and these sample rates: 8000, 11025, 12000, 16000, 22050, 24000, 32000, 44100, or 48000 Hz. For recording, the supported configurations are device-dependent, however generally 16000 Hz mono 16-bit signed is usually available.
Note that the field samplesPerSec is actually in units of milliHz, despite the misleading name. To avoid accidentally using the wrong value, you should initialize this field using one of the symbolic constants defined for this purpose (such as SL_SAMPLINGRATE_44_1 etc.)

Platform configuration

...OpenSL ES for Android is designed for multi-threaded applications, and is thread-safe.
OpenSL ES for Android supports a single engine per application, and up to 32 objects. Available device memory and CPU may further restrict the usable number of objects.
slCreateEngine recognizes, but ignores, these engine options:

• SL_ENGINEOPTION_THREADSAFE
• SL_ENGINEOPTION_LOSSOFCONTROL

Planning for source compatibility [things to be very careful about]

...SL_DATAFORMAT_PCM does not permit the application to specify the representation of the data as signed integer, unsigned integer, or floating-point. The Android implementation assumes that 8-bit data is unsigned integer and 16-bit is signed integer. In addition, the field samplesPerSec is a misnomer, as the actual units are milliHz. These issues are expected to be addressed in the next OpenSL ES version, which will introduce a new extended PCM data format that permits the application to explicitly specify the representation, and corrects the field name. As this will be a new data format, and the current PCM data format will still be available (though deprecated), it should not require any immediate changes to your code.

...The Android simple buffer queue data locator and interface are identical to the OpenSL ES 1.0.1 buffer queue locator and interface, except that Android simple buffer queues may be used with both audio players and audio recorders, and are limited to PCM data format. [OpenSL ES 1.0.1 buffer queues are for audio players only, and are not restricted to PCM data format.]
For recording, the application should enqueue empty buffers. Upon notification of completion via a registered callback, the filled buffer is available for the application to read.
For playback there is no difference. But for future source code compatibility, we suggest that applications use Android simple buffer queues instead of OpenSL ES 1.0.1 buffer queues.

Objects and interface initialization

[Important to review this section extensively to understand how OpenSL operates. No room to paste it all here.]

[found these bits interesting]

...Callback handlers are called from internal non-application thread(s) which are not attached to the Dalvik virtual machine and thus are ineligible to use JNI...

Performance

As OpenSL ES is a native C API, non-Dalvik application threads which call OpenSL ES have no Dalvik-related overhead such as garbage collection pauses. However, there is no additional performance benefit to the use of OpenSL ES other than this. In particular, use of OpenSL ES does not result in lower audio latency, higher scheduling priority, etc. than what the platform generally provides. On the other hand, as the Android platform and specific device implementations continue to evolve, an OpenSL ES application can expect to benefit from any future system performance improvements.

}

Liar! Blasphemer!!!

I don't see the connection! Huh? What? If you can figure out how the above link is indirectly connected to an industrial metal group from the 80's and 90's you get a gold star.

The official Khronos site on OpenSL ES. (Non-specific to Android of course)
http://www.khronos.org/opensles/

NOTE:I must apologize that there isn't some sort of tutorial or sample code or anything here.  Unfortunately, I had to shift gears and run off and go a different direction for a while, so I never did really get into OpenSL ES any further (YET!).  Those links are all I've got.