diff --git a/src/compatibility/4.0/android-4.0-cdd.pdf b/src/compatibility/4.0/android-4.0-cdd.pdf
index f6c06a5..3de021a 100755
--- a/src/compatibility/4.0/android-4.0-cdd.pdf
+++ b/src/compatibility/4.0/android-4.0-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.1/android-4.1-cdd.pdf b/src/compatibility/4.1/android-4.1-cdd.pdf
index 46b6482..270a2d0 100644
--- a/src/compatibility/4.1/android-4.1-cdd.pdf
+++ b/src/compatibility/4.1/android-4.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/4.2/android-4.2-cdd.pdf b/src/compatibility/4.2/android-4.2-cdd.pdf
index 10addf3..f61708d 100755
--- a/src/compatibility/4.2/android-4.2-cdd.pdf
+++ b/src/compatibility/4.2/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-4.0-cdd.pdf b/src/compatibility/android-4.0-cdd.pdf
index f6c06a5..3de021a 100644
--- a/src/compatibility/android-4.0-cdd.pdf
+++ b/src/compatibility/android-4.0-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-4.1-cdd.pdf b/src/compatibility/android-4.1-cdd.pdf
old mode 100755
new mode 100644
index 46b6482..270a2d0
--- a/src/compatibility/android-4.1-cdd.pdf
+++ b/src/compatibility/android-4.1-cdd.pdf
Binary files differ
diff --git a/src/compatibility/android-4.2-cdd.pdf b/src/compatibility/android-4.2-cdd.pdf
old mode 100755
new mode 100644
index 10addf3..f61708d
--- a/src/compatibility/android-4.2-cdd.pdf
+++ b/src/compatibility/android-4.2-cdd.pdf
Binary files differ
diff --git a/src/devices/audio_preprocessing.jd b/src/devices/audio_preprocessing.jd
deleted file mode 100644
index 4beb7e0..0000000
--- a/src/devices/audio_preprocessing.jd
+++ /dev/null
@@ -1,111 +0,0 @@
-page.title=Audio Warmup
-@jd:body
-
-<!--
-    Copyright 2010 The Android Open Source Project
-
-    Licensed under the Apache License, Version 2.0 (the "License");
-    you may not use this file except in compliance with the License.
-    You may obtain a copy of the License at
-
-        http://www.apache.org/licenses/LICENSE-2.0
-
-    Unless required by applicable law or agreed to in writing, software
-    distributed under the License is distributed on an "AS IS" BASIS,
-    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-    See the License for the specific language governing permissions and
-    limitations under the License.
--->
-<div id="qv-wrapper">
-  <div id="qv">
-    <h2>In this document</h2>
-    <ol id="auto-toc">
-    </ol>
-  </div>
-</div>
-
-<p>Audio warmup is the time for the audio amplifier circuit in your device to
-be fully powered and reach its normal operation state. The major contributors
-to audio warmup time are power management and any "de-pop" logic to stabilize
-the circuit.
-</p>
-
-<p>This document describes how to measure audio warmup time and possible ways to decrease
-warmup time.</p>
-
-<h2 id="measuringOutput">Measuring Output Warmup</h2>
-
-<p>
-  AudioFlinger's FastMixer thread automatically measures output warmup
-  and reports it as part of the output of the <code>dumpsys media.audio_flinger</code> command.
-  At warmup, FastMixer calls <code>write()</code>
-  repeatedly until the time between two <code>write()</code>s is the amount expected.
-  FastMixer determines audio warmup by seeing how long a HAL <code>write()</code> takes to stabilize. 
-</p>
-
-<p>To measure audio warmup, do the following
-steps for the built-in speaker and wired headphones and at different times after booting.
-Warmup times are usually different for each output device and right after booting the device:</p>
-
-<ol>
-  <li>Ensure that FastMixer is enabled.</li>
-  <li>Enable touch sounds by selecting <b>Settings > Sound > Touch sounds</b> on the device.</li>
-  <li>Ensure that audio has been off for at least three seconds. Five seconds or more is better, because
-  the hardware itself might have its own power logic beyond the three seconds that AudioFlinger has.</li>
-  <li>Press Home, and you should hear a click sound.</li>
-  <li>Run the following command to receive the measured warmup:
-  <pre>adb shell dumpsys media.audio_flinger | grep measuredWarmup</code></pre>
-
-<p>
-You should see output like this:
-</p>
-
-<pre>
-sampleRate=44100 frameCount=256 measuredWarmup=X ms, warmupCycles=X
-</pre>
-
-<p>
-  The <code>measuredWarmup=X</code> is X number of milliseconds
-  it took for the first set of HAL <code>write()</code>s to complete.
-</p>
-
-<p>
-  The <code>warmupCycles=X</code> is how many HAL write requests it took
-  until the execution time of <code>write()</code> matches what is expected.
-</p>
-</li>
-<li>
-  Take five measurements and report them all, as well as the mean.
-  If they are not all approximately the same,
-  then it’s likely that a measurement is incorrect.
-  For example, if you don’t wait long enough after the audio has been off,
-  you will see a lower warmup time than the mean value.
-</li>
-</ol>
-
-
-<h2 id="measuringInput">Measuring Input Warmup</h2>
-
-<p>
-  There are currently no tools provided for measuring audio input warmup.
-  However, input warmup time can be estimated by observing
-  the time required for <a href="http://developer.android.com/reference/android/media/AudioRecord.html#startRecording()">startRecording()</a>
-  to return. 
-</p>
-
-
-<h2 id="reducing">Reducing Warmup Time</h2>
-
-<p>
-  Warmup time can usually be reduced by a combination of:
-  <ul>
-  <li>Good circuit design</li>
-  <li>Accurate time delays in kernel device driver</li>
-  <li>Performing independent warmup operations concurrently rather than sequentially</li>
-  <li>Leaving circuits powered on or not reconfiguring clocks (increases idle power consumption).
-  <li>Caching computed parameters</li>
-  </ul>
-  However, beware of excessive optimization. You may find that you
-  need to tradeoff between low warmup time versus
-  lack of popping at power transitions.
-</p>
diff --git a/src/devices/audio_terminology.jd b/src/devices/audio_terminology.jd
index f625850..eee03aa 100644
--- a/src/devices/audio_terminology.jd
+++ b/src/devices/audio_terminology.jd
@@ -23,6 +23,13 @@
 
 <dl>
 
+<dt>acoustics</dt>
+<dd>
+The study of the mechanical properties of sound, for example how the
+physical placement of transducers such as speakers and microphones on
+a device affects perceived audio quality.
+</dd>
+
 <dt>bits per sample or bit depth</dt>
 <dd>
 Number of bits of information per sample.
@@ -45,6 +52,16 @@
 for example the audio HAL interface uses this concept.
 </dd>
 
+<dt>Hz</dt>
+<dd>
+The units for sample rate or frame rate.
+</dd>
+
+<dt>latency</dt>
+<dd>
+Time delay as a signal passes through a system.
+</dd>
+
 <dt>mono</dt>
 <dd>
 One channel.
@@ -89,6 +106,13 @@
 tinyalsa.
 </dd>
 
+<dt>AudioEffect</dt>
+<dd>
+An API and implementation framework for output (post-processing) effects
+and input (pre-processing) effects.  The API is defined at
+<a class="external-link" href="http://developer.android.com/reference/android/media/audiofx/AudioEffect.html" target="_android">android.media.audiofx.AudioEffect</a>
+</dd>
+
 <dt>AudioFlinger</dt>
 <dd>
 The sound server implementation for Android. AudioFlinger
@@ -166,6 +190,13 @@
 content, or content which includes multi-media audio and video tracks.
 </dd>
 
+<dt>media.log</dt>
+<dd>
+An AudioFlinger debugging feature, available in custom builds only,
+for logging audio events to a circular buffer where they can then be
+dumped retroactively when needed.
+</dd>
+
 <dt>mediaserver</dt>
 <dd>
 An Android system process that contains a number of media-related
@@ -201,6 +232,14 @@
 to pass control information.
 </dd>
 
+<dt>tee sink</dt>
+<dd>
+An AudioFlinger debugging feature, available in custom builds only,
+for retaining a short fragment of recent audio for later analysis.
+This permits comparison between what was actually played or recorded
+vs. what was expected.
+</dd>
+
 <dt>tinyalsa</dt>
 <dd>
 A small user-mode API above ALSA kernel with BSD license, recommended
diff --git a/src/source/code-style.jd b/src/source/code-style.jd
index bb633fb..99bfbb3 100644
--- a/src/source/code-style.jd
+++ b/src/source/code-style.jd
@@ -378,7 +378,7 @@
 <p>The use and location of static imports have been mildly controversial
 issues. Some people would prefer static imports to be interspersed with the
 remaining imports, some would prefer them reside above or below all other
-imports. Additinally, we have not yet come up with a way to make all IDEs use
+imports. Additionally, we have not yet come up with a way to make all IDEs use
 the same ordering.</p>
 <p>Since most people consider this a low priority issue, just use your
 judgement and please be consistent.</p>