From 45a4bde322c3c39ca0e57143d0f0655bc1b6c8e4 Mon Sep 17 00:00:00 2001 From: Glenn Kasten Date: Mon, 22 Apr 2013 13:49:43 -0700 Subject: Add audio latency design Change-Id: Ib3b5ade2950d8b2893ca3dc54676cca86f08853a --- src/devices/devices_toc.cs | 1 + src/devices/latency_design.jd | 215 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 216 insertions(+) create mode 100644 src/devices/latency_design.jd diff --git a/src/devices/devices_toc.cs b/src/devices/devices_toc.cs index 84e838ba..36ac8cc2 100644 --- a/src/devices/devices_toc.cs +++ b/src/devices/devices_toc.cs @@ -35,6 +35,7 @@
  • Latency
  • Warmup
  • Avoiding Priority Inversion
    • +
  • Design For Reduced Latency
  • Camera v1
    • diff --git a/src/devices/latency_design.jd b/src/devices/latency_design.jd new file mode 100644 index 00000000..8e6d7664 --- /dev/null +++ b/src/devices/latency_design.jd @@ -0,0 +1,215 @@ +page.title=Design For Reduced Latency +@jd:body + +
    +
    +

    In this document

    +
      +
    +
    +
    + +

    +Android 4.1 (Jelly Bean) 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 +and chipsets. This article is not intended for application developers. +

    + +

    Track Creation

    + +

    +The client can optionally set bit AUDIO_OUTPUT_FLAG_FAST in the +audio_output_flags_t parameter of AudioTrack C++ constructor or +AudioTrack::set(). Currently the only clients that do so are: +

    + + + +

    +The AudioTrack C++ implementation reviews the AUDIO_OUTPUT_FLAG_FAST +request and may optionally deny the request at client level. If it +decides to pass the request on, it does so using TRACK_FAST bit of +the track_flags_t parameter of the IAudioTrack factory method +IAudioFlinger::createTrack(). +

    + +

    +AudioFlinger (server) reviews the TRACK_FAST request and may +optionally deny the request at server level. It informs the client +whether or not the request was accepted, via bit CBLK_FAST of the +shared memory control block. +

    + +

    +The factors that impact the decision include: +

    + + + +

    +If the client's request was accepted, it is called a "fast track", +otherwise it's called a "normal track". +

    + +

    Mixer Threads

    + +

    +At the time AudioFlinger creates a normal mixer thread, it decides +whether or not to also create a fast mixer thread. Both the normal +mixer and fast mixer are not associated with a particular track, +but rather with a set of tracks. There is always a normal mixer +thread. The fast mixer thread, if it exists, is subservient to the +normal mixer thread and acts under its control. +

    + +

    Fast mixer

    + +

    Features

    + +

    +The fast mixer thread provides these features: +

    + + + +

    +Omitted features: +

    + + + +

    Period

    + +

    +The fast mixer runs periodically, with a recommended period of 2 +to 3 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 +and chance of glitches depending on CPU scheduling predictability. +Larger values are possible, up to 20 ms, but result in degraded +total latency and so should be avoided. +

    + +

    Scheduling

    + +

    +The fast mixer runs at elevated SCHED_FIFO priority. It needs very +little CPU time, but must run often and with low scheduling jitter. +Running too late will result in glitches due to underrun. Running +too early will result in glitches due to pulling from a fast track +before the track has provided data. +

    + +

    Blocking

    + +

    +Ideally the fast mixer thread never blocks, other than at HAL +write(). Other occurrences of blocking within the fast mixer are +considered bugs. In particular, mutexes are avoided. +

    + +

    Relationship to other components

    + +

    +The fast mixer has little direct interaction with clients. In +particular, it does not see binder-level operations, but it does +access the client's shared memory control block. +

    + +

    +The fast mixer receives commands from the normal mixer via a state queue. +

    + +

    +Other than pulling track data, interaction with clients is via the normal mixer. +

    + +

    +The fast mixer's primary sink is the audio HAL. +

    + +

    Normal mixer

    + +

    Features

    + +

    +All features are enabled: +

    + + + +

    Period

    + +

    +The period is computed to be the first integral multiple of the +fast mixer period that is >= 20 milliseconds. +

    + +

    Scheduling

    + +

    +The normal mixer runs at elevated SCHED_OTHER priority. +

    + +

    Blocking

    + +

    +The normal mixer is permitted to block, and often does so at various +mutexes as well as at a blocking pipe to write its sub-mix. +

    + +

    Relationship to other components

    + +

    +The normal mixer interacts extensively with the outside world, +including binder threads, audio policy manager, fast mixer thread, +and client tracks. +

    + +

    +The normal mixer's sink is a blocking pipe to the fast mixer's track 0. +

    + +

    Flags

    + +

    +AUDIO_OUTPUT_FLAG_FAST bit is a hint. There's no guarantee the +request will be fulfilled. +

    + +

    +AUDIO_OUTPUT_FLAG_FAST is a client-level concept. It does not appear +in server. +

    + +

    +TRACK_FAST is a client -> server concept. +

    + -- cgit v1.2.3