diff options
| -rw-r--r-- | src/devices/audio.jd | 54 | ||||
| -rw-r--r-- | src/devices/audio_avoiding_pi.jd | 38 | ||||
| -rw-r--r-- | src/devices/audio_latency.jd | 50 | ||||
| -rw-r--r-- | src/devices/audio_terminology.jd | 13 | ||||
| -rw-r--r-- | src/devices/audio_warmup.jd | 13 | ||||
| -rw-r--r-- | src/devices/latency_design.jd | 16 | ||||
| -rw-r--r-- | src/devices/testing_circuit.jd | 6 |
7 files changed, 103 insertions, 87 deletions
diff --git a/src/devices/audio.jd b/src/devices/audio.jd index 8b58d9e1..1192830c 100644 --- a/src/devices/audio.jd +++ b/src/devices/audio.jd @@ -25,7 +25,7 @@ page.title=Audio </div> <p> - Android's audio HAL connects the higher level, audio-specific + Android's audio Hardware Abstraction Layer (HAL) connects the higher level, audio-specific framework APIs in <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a> to the underlying audio driver and hardware. </p> @@ -45,7 +45,7 @@ page.title=Audio At the application framework level is the app code, which utilizes the <a href="http://developer.android.com/reference/android/media/package-summary.html">android.media</a> APIs to interact with the audio hardware. Internally, this code calls corresponding JNI glue - classes to access the native code that interacts with the auido hardware. + classes to access the native code that interacts with the audio hardware. </dd> <dt> JNI @@ -82,9 +82,11 @@ page.title=Audio HAL </dt> <dd> - The hardware abstraction layer defines the standard interface that audio services calls into + The HAL defines the standard interface that audio services call into and that you must implement to have your audio hardware function correctly. The audio HAL - interfaces are located in <code>hardware/libhardware/include/hardware</code>. + interfaces are located in +<code>hardware/libhardware/include/hardware</code>. See <a +href="http://source.android.com/devices/reference/audio_8h_source.html">audio.h</a> for additional details. </dd> <dt> Kernel Driver @@ -130,14 +132,15 @@ Also, see header files for a reference of the properties that you can define. </p> <h3 id="multichannel">Multi-channel support</h3> -<p>If your hardware and driver supports multi-channel audio via HDMI, you can output the audio stream +<p>If your hardware and driver supports multichannel audio via HDMI, you can output the audio stream directly to the audio hardware. This bypasses the AudioFlinger mixer so it doesn't get downmixed to two channels. <p> - The audio HAL must expose whether an output stream profile supports multi-channel audio capabilities. + The audio HAL must expose whether an output stream profile supports multichannel audio capabilities. If the HAL exposes its capabilities, the default policy manager allows multichannel playback over HDMI.</p> - <p>For more implementation details, see the <code>device/samsung/tuna/audio/audio_hw.c</code> in the Jellybean release.</p> + <p>For more implementation details, see the +<code>device/samsung/tuna/audio/audio_hw.c</code> in the Android 4.1 release.</p> <p> To specify that your product contains a multichannel audio output, edit the <code>audio_policy.conf</code> file to describe the multichannel @@ -165,18 +168,18 @@ audio_hw_modules { </pre> - <p>If your product does not support multichannel audio, AudioFlinger's mixer downmixes the content to stereo + <p>AudioFlinger's mixer downmixes the content to stereo automatically when sent to an audio device that does not support multichannel audio.</p> </p> -<h3 id="codecs">Media Codecs</h3> +<h3 id="codecs">Media codecs</h3> -<p>Ensure that the audio codecs that your hardware and drivers support are properly declared for your product. See +<p>Ensure the audio codecs your hardware and drivers support are properly declared for your product. See <a href="media.html#expose"> Exposing Codecs to the Framework</a> for information on how to do this. </p> <h2 id="configuring"> - Configuring the Shared Library + Configuring the shared library </h2> <p> You need to package the HAL implementation into a shared library and copy it to the @@ -192,7 +195,7 @@ audio_hw_modules { LOCAL_MODULE := audio.primary.<device_name> </pre> <p> - Notice that your library must be named <code>audio_primary.<device_name>.so</code> so + Notice your library must be named <code>audio_primary.<device_name>.so</code> so that Android can correctly load the library. The "<code>primary</code>" portion of this filename indicates that this shared library is for the primary audio hardware located on the device. The module names <code>audio.a2dp.<device_name></code> and @@ -249,24 +252,27 @@ PRODUCT_PACKAGES += \ </li> </ol> -<h2 id="preprocessing">Audio preprocessing effects</h2> +<h2 id="preprocessing">Audio pre-processing effects</h2> <p> -The Android platform supports audio effects on supported devices in the +The Android platform provides audio effects on supported devices in the <a href="http://developer.android.com/reference/android/media/audiofx/package-summary.html">audiofx</a> package, which is available for developers to access. For example, on the Nexus 10, the following pre-processing effects are supported: </p> <ul> - <li><a href="http://developer.android.com/reference/android/media/audiofx/AcousticEchoCanceler.html">Acoustic Echo Cancellation</a></li> - <li><a href="http://developer.android.com/reference/android/media/audiofx/AutomaticGainControl.html">Automatic Gain Control</a></li> - <li><a href="http://developer.android.com/reference/android/media/audiofx/NoiseSuppressor.html">Noise Suppression</a></li> + <li><a +href="http://developer.android.com/reference/android/media/audiofx/AcousticEchoCanceler.html">Acoustic Echo Cancellation</a></li> + <li><a +href="http://developer.android.com/reference/android/media/audiofx/AutomaticGainControl.html">Automatic Gain Control</a></li> + <li><a +href="http://developer.android.com/reference/android/media/audiofx/NoiseSuppressor.html">Noise Suppression</a></li> </ul> </p> <p>Pre-processing effects are always paired with the use case mode in which the pre-processing is requested. In Android -app development, a use case is referred to as an <code>AudioSource</code>, and app developers -request to use the <code>AudioSource</code> abstraction instead of the actual audio hardware device to use. +app development, a use case is referred to as an <code>AudioSource</code>; and app developers +request to use the <code>AudioSource</code> abstraction instead of the actual audio hardware device. The Android Audio Policy Manager maps an <code>AudioSource</code> to the actual hardware with <code>AudioPolicyManagerBase::getDeviceForInputSource(int -inputSource)</code>. In Android 4.2, the following sources are exposed to developers: +inputSource)</code>. The following sources are exposed to developers: </p> <ul> <code><li>android.media.MediaRecorder.AudioSource.CAMCORDER</li></code> @@ -288,11 +294,13 @@ see the implementation for the Nexus 10 in <code>device/samsung/manta/audio_effe <p class="warning"><strong>Warning:</strong> For the <code>VOICE_RECOGNITION</code> use case, do not enable the noise suppression pre-processing effect. It should not be turned on by default when recording from this audio source, and you should not enable it in your own audio_effects.conf file. Turning on the effect by default will cause the device to fail -the <a href="/compatibility/index.html"> compatibility requirement </a> -regardless of whether is was on by default due to configuration file, or the audio HAL implementation's default behavior.</p> +the <a href="/compatibility/index.html">compatibility requirement</a> regardless of whether this was on by default due to +configuration file, or the audio HAL implementation's default behavior.</p> <p>The following example enables pre-processing for the VoIP <code>AudioSource</code> and Camcorder <code>AudioSource</code>. -By declaring the <code>AudioSource</code> configuration in this manner, the framework will automatically request from the audio HAL the use of those effects</p> +By declaring the <code>AudioSource</code> configuration in this manner, the +framework will automatically request from the audio HAL the use of those +effects.</p> <pre> pre_processing { diff --git a/src/devices/audio_avoiding_pi.jd b/src/devices/audio_avoiding_pi.jd index 184a1509..a8cd208c 100644 --- a/src/devices/audio_avoiding_pi.jd +++ b/src/devices/audio_avoiding_pi.jd @@ -11,34 +11,34 @@ page.title=Avoiding Priority Inversion <p> This article explains how the Android's audio system attempts to avoid -priority inversion, as of the Android 4.1 (Jellybean) release, +priority inversion, as of the Android 4.1 release, and highlights techniques that you can use too. </p> <p> These techniques may be useful to developers of high-performance audio apps, OEMs, and SoC providers who are implementing an audio -HAL. Please note that implementing these techniques is not +HAL. Please note implementing these techniques is not guaranteed to prevent glitches or other failures, particularly if used outside of the audio context. -Your results may vary and you should conduct your own +Your results may vary, and you should conduct your own evaluation and testing. </p> <h2 id="background">Background</h2> <p> -The Android audio server "AudioFlinger" and AudioTrack/AudioRecord +The Android AudioFlinger audio server and AudioTrack/AudioRecord client implementation are being re-architected to reduce latency. -This work started in Android 4.1 (Jellybean), continued in 4.2 -(Jellybean MR1), and more improvements are likely in "K". +This work started in Android 4.1, continued in 4.2 and 4.3, and now more +improvements exist in version 4.4. </p> <p> -The lower latency needed many changes throughout the system. One -important change was to assign CPU resources to time-critical +To achieve this lower latency, many changes were needed throughout the system. One +important change is to assign CPU resources to time-critical threads with a more predictable scheduling policy. Reliable scheduling -allows the audio buffer sizes and counts to be reduced, while still +allows the audio buffer sizes and counts to be reduced while still avoiding artifacts due to underruns. </p> @@ -64,7 +64,7 @@ are used, or delay in responding to a command. <p> In the Android audio implementation, priority inversion is most -likely to occur in these places, and so we focus attention here: +likely to occur in these places. And so we focus attention here: </p> <ul> @@ -80,7 +80,7 @@ different priorities) </li> <li> -within the audio HAL implementation, e.g. for telephony or echo cancellation +within the audio Hardware Abstraction Layer (HAL) implementation, e.g. for telephony or echo cancellation </li> <li> @@ -119,7 +119,7 @@ priority inheritance mutexes <p> Disabling interrupts is not feasible in Linux user space, and does -not work for SMP. +not work for Symmetric Multi-Processors (SMP). </p> @@ -162,15 +162,15 @@ such as: </ul> <p> -All of these return the previous value, and include the necessary +All of these return the previous value and include the necessary SMP barriers. The disadvantage is they can require unbounded retries. In practice, we've found that the retries are not a problem. </p> <p> -Note: atomic operations and their interactions with memory barriers +<strong>Note</strong>: Atomic operations and their interactions with memory barriers are notoriously badly misunderstood and used incorrectly. We include -these here for completeness, but recommend you also read the article +these methods here for completeness but recommend you also read the article <a href="https://developer.android.com/training/articles/smp.html"> SMP Primer for Android</a> for further information. @@ -202,7 +202,7 @@ low-priority modules. When state does need to be shared, limit the state to the maximum-size <a href="http://en.wikipedia.org/wiki/Word_(computer_architecture)">word</a> -that can be accessed atomically in one bus operation +that can be accessed atomically in one-bus operation without retries. </li> @@ -244,7 +244,7 @@ we've found them to be complex and error-prone. </p> <p> -In Android 4.2 (Jellybean MR1), you can find our non-blocking, +Starting in Android 4.2, you can find our non-blocking, single-reader/writer classes in these locations: </p> @@ -267,14 +267,14 @@ frameworks/av/services/audioflinger/StateQueue* <p> These were designed specifically for AudioFlinger and are not general-purpose. Non-blocking algorithms are notorious for being -difficult to debug. You can look at this code as a model, but be +difficult to debug. You can look at this code as a model. But be aware there may be bugs, and the classes are not guaranteed to be suitable for other purposes. </p> <p> For developers, we may update some of the sample OpenSL ES application -code to use non-blocking, or referencing a non-Android open source +code to use non-blocking algorithms or reference a non-Android open source library. </p> diff --git a/src/devices/audio_latency.jd b/src/devices/audio_latency.jd index 476842b3..2a1d2d79 100644 --- a/src/devices/audio_latency.jd +++ b/src/devices/audio_latency.jd @@ -26,8 +26,10 @@ page.title=Audio Latency <p>Audio latency is the time delay as an audio signal passes through a system. For a complete description of audio latency for the purposes of Android - compatibility, see <em>Section 5.4 Audio Latency</em> + compatibility, see <em>Section 5.5 Audio Latency</em> in the <a href="http://source.android.com/compatibility/index.html">Android CDD</a>. + See <a href="latency_design.html">Design For Reduced Latency</a> for an + understanding of Android's audio latency-reduction efforts. </p> <h2 id="contributors">Contributors to Latency</h2> @@ -37,8 +39,8 @@ page.title=Audio Latency but a similar discussion applies to input latency. </p> <p> - Assuming that the analog circuitry does not contribute significantly. - Then the major surface-level contributors to audio latency are the following: + Assuming the analog circuitry does not contribute significantly, then the major +surface-level contributors to audio latency are the following: </p> <ul> @@ -53,14 +55,14 @@ page.title=Audio Latency The reason is that buffer count and buffer size are more of an <em>effect</em> than a <em>cause</em>. What usually happens is that a given buffer scheme is implemented and tested, but during testing, an audio - underrun is heard as a "click" or "pop". To compensate, the + underrun is heard as a "click" or "pop." To compensate, the system designer then increases buffer sizes or buffer counts. This has the desired result of eliminating the underruns, but it also has the undesired side effect of increasing latency. </p> <p> - A better approach is to understand the underlying causes of the + A better approach is to understand the causes of the underruns and then correct those. This eliminates the audible artifacts and may even permit even smaller or fewer buffers and thus reduce latency. @@ -95,7 +97,7 @@ page.title=Audio Latency <p> The obvious solution is to avoid CFS for high-performance audio - threads. Beginning with Android 4.1 (Jelly Bean), such threads now use the + threads. Beginning with Android 4.1, such threads now use the <code>SCHED_FIFO</code> scheduling policy rather than the <code>SCHED_NORMAL</code> (also called <code>SCHED_OTHER</code>) scheduling policy implemented by CFS. </p> @@ -107,17 +109,17 @@ page.title=Audio Latency non-audio user threads with policy <code>SCHED_FIFO</code>. The available <code>SCHED_FIFO</code> priorities range from 1 to 99. The audio threads run at priority 2 or 3. This leaves priority 1 available for lower priority threads, - and priorities 4 to 99 for higher priority threads. We recommend that + and priorities 4 to 99 for higher priority threads. We recommend you use priority 1 whenever possible, and reserve priorities 4 to 99 for those threads that are guaranteed to complete within a bounded amount - of time, and are known to not interfere with scheduling of audio threads. + of time and are known to not interfere with scheduling of audio threads. </p> <h3>Scheduling latency</h3> <p> Scheduling latency is the time between when a thread becomes ready to run, and when the resulting context switch completes so that the - thread actually runs on a CPU. The shorter the latency the better and + thread actually runs on a CPU. The shorter the latency the better, and anything over two milliseconds causes problems for audio. Long scheduling latency is most likely to occur during mode transitions, such as bringing up or shutting down a CPU, switching between a security kernel @@ -129,7 +131,7 @@ page.title=Audio Latency <p> In many designs, CPU 0 services all external interrupts. So a long-running interrupt handler may delay other interrupts, in particular - audio DMA completion interrupts. Design interrupt handlers + audio direct memory access (DMA) completion interrupts. Design interrupt handlers to finish quickly and defer any lengthy work to a thread (preferably a CFS thread or <code>SCHED_FIFO</code> thread of priority 1). </p> @@ -148,7 +150,8 @@ page.title=Audio Latency <p> There are several techniques available to measure output latency, - with varying degrees of accuracy and ease of running. + with varying degrees of accuracy and ease of running, described below. Also +see the <a href="testing_circuit.html">Testing circuit</a> for an example test environment. </p> <h3>LED and oscilloscope test</h3> @@ -167,8 +170,8 @@ If your production device does not have an LED, you can install the </p> <ul> - <li>Use a General Purpose Input/Output (GPIO) pin for the same purpose</li> - <li>Use JTAG or another debugging port</li> + <li>Use a General Purpose Input/Output (GPIO) pin for the same purpose.</li> + <li>Use JTAG or another debugging port.</li> <li>Use the screen backlight. This might be risky as the backlight may have a non-neglible latency, and can contribute to an inaccurate latency reading. @@ -183,8 +186,8 @@ If your production device does not have an LED, you can install the <p class="note"><b>Note:</b> To get useful results, it is crucial to use the correct APIs in the test app so that you're exercising the fast audio output path. - See the separate document "Application developer guidelines for reduced - audio latency". <!-- where is this ?--> + See <a href="latency_design.html">Design For Reduced Latency</a> for + background. </p> </li> <li>Place a light sensor next to the LED.</li> @@ -198,7 +201,7 @@ If your production device does not have an LED, you can install the <p>The difference in time is the approximate audio output latency, assuming that the LED latency and light sensor latency are both zero. Typically, the LED and light sensor each have a relatively low latency - on the order of 1 millisecond or less, which is sufficiently low enough + on the order of one millisecond or less, which is sufficiently low enough to ignore.</p> <h3>Larsen test</h3> @@ -206,7 +209,8 @@ If your production device does not have an LED, you can install the One of the easiest latency tests is an audio feedback (Larsen effect) test. This provides a crude measure of combined output and input latency by timing an impulse response loop. This test is not very useful - by itself because of the nature of the test, but</p> + by itself because of the nature of the test, but it can be useful for calibrating + other tests</p> <p>To conduct this test:</p> <ol> @@ -219,7 +223,7 @@ If your production device does not have an LED, you can install the <p>This method does not break down the component times, which is important when the output latency - and input latency are independent, so this method is not recommended for measuring output latency, but might be useful + and input latency are independent. So this method is not recommended for measuring output latency, but might be useful to help measure output latency.</p> <h2 id="measuringInput">Measuring Input Latency</h2> @@ -270,7 +274,7 @@ overall. </p> <ul> <li>Configure any DSP after the app processor so that it adds - minimal latency</li> + minimal latency.</li> <li>Run tests under different conditions such as having the screen on or off, USB plugged in or unplugged, WiFi on or off, Bluetooth on or off, and telephony and data radios @@ -278,7 +282,7 @@ overall. <li>Select relatively quiet music that you're very familiar with, and which is easy to hear underruns in.</li> <li>Use wired headphones for extra sensitivity.</li> - <li>Give yourself breaks so that you don't experience "ear fatigue".</li> + <li>Give yourself breaks so that you don't experience "ear fatigue."</li> </ul> <p> @@ -297,11 +301,11 @@ overall. <p> The output of <code>dumpsys media.audio_flinger</code> also contains a - useful section called "simple moving statistics". This has a summary + useful section called "simple moving statistics." This has a summary of the variability of elapsed times for each audio mix and I/O cycle. Ideally, all the time measurements should be about equal to the mean or nominal cycle time. If you see a very low minimum or high maximum, this is an - indication of a problem, which is probably a high scheduling latency or interrupt + indication of a problem, likely a high scheduling latency or interrupt disable time. The <i>tail</i> part of the output is especially helpful, as it highlights the variability beyond +/- 3 standard deviations. -</p>
\ No newline at end of file +</p> diff --git a/src/devices/audio_terminology.jd b/src/devices/audio_terminology.jd index eee03aaa..23592d43 100644 --- a/src/devices/audio_terminology.jd +++ b/src/devices/audio_terminology.jd @@ -76,7 +76,7 @@ A number representing the audio value for a single channel at a point in time. <dd> Number of frames per second; note that "frame rate" is thus more accurate, -but "sample rate" is conventionally used to mean "frame rate". +but "sample rate" is conventionally used to mean "frame rate." </dd> <dt>stereo</dt> @@ -89,7 +89,7 @@ Two channels. <h2 id="androidSpecificTerms">Android-Specific Terms</h2> <p> -These are terms that are specific to Android audio framework, or that +These are terms specific to the Android audio framework, or that may have a special meaning within Android beyond their general meaning. </p> @@ -135,7 +135,8 @@ or a software application, rather than a software module within a system. <dt>AudioRecord</dt> <dd> The primary low-level client API for receiving data from an audio -input device such as microphone. The data is usually in PCM format. +input device such as microphone. The data is usually in pulse-code modulation +(PCM) format. </dd> <dt>AudioResampler</dt> @@ -187,7 +188,7 @@ An AudioTrack client with lower latency but fewer features, on some devices. <dt>MediaPlayer</dt> <dd> A higher-level client API than AudioTrack, for playing either encoded -content, or content which includes multi-media audio and video tracks. +content, or content which includes multimedia audio and video tracks. </dd> <dt>media.log</dt> @@ -215,7 +216,7 @@ NBAIO are for pipes of various kinds. <dd> A thread within AudioFlinger that services most full-featured AudioTrack clients, and either directly drives an output device or feeds -it's sub-mix into FastMixer via a pipe. +its sub-mix into FastMixer via a pipe. </dd> <dt>OpenSL ES</dt> @@ -243,7 +244,7 @@ vs. what was expected. <dt>tinyalsa</dt> <dd> A small user-mode API above ALSA kernel with BSD license, recommended -for use by HAL implementations. +for use in HAL implementations. </dd> <dt>track</dt> diff --git a/src/devices/audio_warmup.jd b/src/devices/audio_warmup.jd index 4beb7e0d..ba1217cd 100644 --- a/src/devices/audio_warmup.jd +++ b/src/devices/audio_warmup.jd @@ -40,12 +40,13 @@ warmup time.</p> 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. + FastMixer determines audio warmup by seeing how long a Hardware Abstraction +Layer (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> +<p>To measure audio warmup, follow these 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> @@ -75,7 +76,7 @@ sampleRate=44100 frameCount=256 measuredWarmup=X ms, warmupCycles=X </p> </li> <li> - Take five measurements and report them all, as well as the mean. + Take five measurements and record 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, @@ -102,7 +103,7 @@ sampleRate=44100 frameCount=256 measuredWarmup=X ms, warmupCycles=X <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>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 diff --git a/src/devices/latency_design.jd b/src/devices/latency_design.jd index 8e6d7664..eb503f30 100644 --- a/src/devices/latency_design.jd +++ b/src/devices/latency_design.jd @@ -10,12 +10,12 @@ page.title=Design For Reduced Latency </div> <p> -Android 4.1 (Jelly Bean) release introduced internal framework changes for +The Android 4.1 release introduced internal framework changes for a lower latency audio output path. There were no public client API or HAL API changes. This document describes the initial design, which is expected to evolve over time. Having a good understanding of this design should help device OEM and -SoC vendors to implement the design correctly on their particular devices +SoC vendors implement the design correctly on their particular devices and chipsets. This article is not intended for application developers. </p> @@ -42,7 +42,7 @@ the <code>track_flags_t</code> parameter of the <code>IAudioTrack</code> factory </p> <p> -AudioFlinger (server) reviews the <code>TRACK_FAST</code> request and may +The AudioFlinger audio server reviews the <code>TRACK_FAST</code> request and may optionally deny the request at server level. It informs the client whether or not the request was accepted, via bit <code>CBLK_FAST</code> of the shared memory control block. @@ -61,8 +61,8 @@ The factors that impact the decision include: </ul> <p> -If the client's request was accepted, it is called a "fast track", -otherwise it's called a "normal track". +If the client's request was accepted, it is called a "fast track." +Otherwise it's called a "normal track." </p> <h2 id="mixerThreads">Mixer Threads</h2> @@ -102,8 +102,8 @@ Omitted features: <h4>Period</h4> <p> -The fast mixer runs periodically, with a recommended period of 2 -to 3 ms, or slightly higher if needed for scheduling stability. +The fast mixer runs periodically, with a recommended period of two +to three milliseconds (ms), or slightly higher if needed for scheduling stability. This number was chosen so that, accounting for the complete buffer pipeline, the total latency is on the order of 10 ms. Smaller values are possible but may result in increased power consumption @@ -169,7 +169,7 @@ All features are enabled: <p> The period is computed to be the first integral multiple of the -fast mixer period that is >= 20 milliseconds. +fast mixer period that is >= 20 ms. </p> <h4>Scheduling</h4> diff --git a/src/devices/testing_circuit.jd b/src/devices/testing_circuit.jd index baee4744..3ad65753 100644 --- a/src/devices/testing_circuit.jd +++ b/src/devices/testing_circuit.jd @@ -13,7 +13,8 @@ page.title=Testing Circuit The file <a href="http://developer.android.com/downloads/partner/audio/av_sync_board.zip">av_sync_board.zip</a> contains CAD files for an A/V sync and latency testing printed circuit board (PCB). -The files include a fabrication drawing, EAGLE CAD, schematic, and BOM. +The files include a fabrication drawing, EAGLE CAD, schematic, and BOM. See <a +href="audio_latency.html">Audio Latency</a> for recommended testing methods. </p> <p> @@ -28,7 +29,8 @@ are negligible relative to the audio. <p> This design is supplied "as is", and we aren't be responsible for any errors in the design. -But if you have any suggestions for improvement, please post to android-porting group. +But if you have any suggestions for improvement, please post to the <a +href="https://groups.google.com/forum/#!forum/android-porting">android-porting</a> group. </p> <p> |