In summary, we saw in this chapter how to initialize OpenSL ES on Android. The engine object is the main entry point to manage all OpenSL objects. Objects in OpenSL follow a specific lifecycle of creation, realization, and destruction. Then, we saw how to play background music from an encoded file and in-memory sounds with a sound buffer queue. Finally, we discovered how to record and then play a sound in a way that is thread-safe and non-blocking.

Do you prefer OpenSL ES over Java APIs? If all you need is a nice high-level API, Java APIs may suit your requirements better. If you need finer playback or recording control, there is no significant difference between low-level Java APIs and OpenSL ES. In this case, the choice should be architectural. If your code is mainly Java, you should probably go with Java.

If you need to reuse an existing sound-related library, optimize the performance, or perform intense computations, such as sound filtering on the fly, OpenSL ES is probably the right choice. OpenSL ES is also the way to go to low-latency, although Android is not quite there yet (fragmentations, device-specific issues, and so on). At the least, this verbose API is probably the one that is going to give the best performance. There is no garbage collector overhead and aggressive optimization is favored in the native code.

Whatever choice you make, know that the Android NDK has a lot more to offer. After dealing with Chapter 6, Rendering Graphics with OpenGL ES and Chapter 7, Playing Sound with OpenSL ES, the next chapter will take care of handling input natively: keyboard, touches, and sensors.