662 APPENDIX A: Audio Concepts, Terminology, and Codecs
Digital Audio Synthesis and Sequencing Caveats
Just like with digital imaging, animation, and digital video, optimizing your digital audio assets is
important for two completely different, but related, reasons. With digital audio samples, especially
in regard to using Android SoundPool, you must consider the amount of system memory needed to
hold each sample once it has been decompressed by the codec and put into its raw, uncompressed
state, inside your Android device’s memory.
The second reason that well-optimized audio is important is the CPU processing part of the
equation. It’s pretty obvious that with less audio (duration, resolution, frequency, and number of
stereo/mono tracks) to process, even if that is just sending the audio data to the audio hardware,
there are less CPU cycles used.
Therefore, if you can get the same basic audio quality results using a lower sample resolution
(fewer bits per slice of audio) or a lower sample frequency (fewer slices of the audio waveform per
second), or fewer tracks (mono or one audio track instead of stereo or two audio tracks), and shorter
playback duration, you will be saving both your Android operating system memory resources and
your user’s Android CPU processing power resources.
The reason I am going into all of this audio sample optimization information in such great detail
in this appendix is because the Android SoundPool class will often get a “bad rap,” because the
raw audio sample sizes that developers provide to SoundPool are too data-heavy. The SoundPool
engine gets blamed for this, rather than the developer’s lacking data footprint optimization skillset.
Google the phrase “SoundPool doesn’t work” and you will see what I mean. Everyone expects
everything to be handed to them on a vinyl platter! Yes, you would really have to be quite ancient,
or a modern day DJ, in order to get that last joke! Actually, vinyl is making a comeback currently.
Raw audio data optimization thus becomes more and more important, at least where SoundPool
is concerned, as the number of digital audio samples that you require increases. This is again true
for both system memory and system processing cycle usage considerations, because as you add
samples, both of these resources are utilized more and more. Don’t forget that there are other things
that your application is doing, like user interface event handling, imaging, animation, digital video,
and possibly even 3D rendering.
Another reason providing highly optimized digital audio samples is so important when using a
SoundPool class is because there is currently a one megabyte limit on digital audio sample data
when using a SoundPool engine. Although this limit might be increased in future Android API
revisions of this digital audio sequencing class, it is still always best practice to optimize any digital
audio assets effectively and efficiently.
Digital audio synthesis and sequencing using SoundPool in your Android app is a balancing act,
both within the device that you are testing it on at the moment, as well as across all devices that
your application will ever be run on.
If a given hardware platform (smartphone, tablet, ereader, iTV set, or smartwatch) cannot handle
playing a given audio data load, then it may simply not play a given sample. As time goes on this will
happen less and less due to better code and faster device processor and memory hardware. As you
have learned thus far, digital audio synthesis, sequencing, and compositing is heavily predicated on
the speed of the processor, the number of processor cores available, and the amount of memory
available to hold all of the digital audio samples needed in their uncompressed format.