Which Stage Is Really the Bottleneck?

Which Stage Is Really the Bottleneck?

Ada re-derives this chapter’s own numbers step by step, at full precision

foundations
math-foundations
calculation-audit
ux-design
Ada ADA · CALCULATION AUDIT

Which Stage Is Really the Bottleneck?

The chapter’s voice-interface latency sums to 1,095 ms — just past the 1,000 ms “It’s broken” cliff — and calls the 220 ms cloud ASR round-trip “the biggest bottleneck.” Yet audio capture at 350 ms and TTS at 310 ms are both larger. This audit ranks the stages to ask which stage is really the bottleneck, and finds ASR is the most fixable, not the biggest.

Companion to the chapter Interface Design: Multimodal Interaction — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is cloud asr time. The middle card applies the page rule. The green card is voice path latency. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

Cloud ASR time changes voice path latency An input card leads through the rule total = 875 ms for other stages + ASR time to the voice path latency result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. Cutting the network round trip can move the full path back below the broken-experience line.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 220 ms.

  2. 2

    Name the relationship. total = 875 ms for other stages + ASR time

  3. 3

    Substitute with units. 875 + 220 = 1,095 ms

  4. 4

    Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change cloud asr time

Try Predict the direction of total = 875 ms for other stages + ASR time. Test another cloud asr time, then compare voice path latency.

220 ms
Chapter baseline
Voice path latency

Observe Cutting the network round trip can move the full path back below the broken-experience line. Reset cloud asr time to 220 and compare voice path latency.

Explain Cutting the network round trip can move the full path back below the broken-experience line.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only cloud asr time moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only cloud asr time. It is not a field prediction.

TryRun Check derivation on the 1,095 ms voice path and retain the 1,000 ms broken-experience threshold.
ObserveThe ranked stage readout places 350 ms capture and 310 ms TTS above the 220 ms cloud ASR round trip.
ExplainA serial latency budget adds all six stages; ASR is a practical optimization target, but its 220 ms term is not the largest contributor.

Ada: The latency budget sums to 1,095 ms, and the chapter calls the 220 ms cloud ASR round-trip “the biggest bottleneck.” The total is right, but “biggest” needs a careful eye, because the largest stage and the most fixable stage are not the same thing.

First the sum, and where it lands:

  • 80 + 350 + 220 + 75 + 60 + 310 = 1,095 ms
  • The perception table marks >1000 ms as “It’s broken,” so the baseline sits just 1,095 - 1,000 = 95 ms over the cliff

Now rank the stages by size:

  • Audio capture 350 ms (32% of the budget), the largest single stage
  • TTS response 310 ms (28%)
  • Cloud ASR 220 ms (20%)

So ASR is only the third largest stage. Audio capture and TTS together are 350 + 310 = 660 ms, 60% of the whole budget. The reason ASR still deserves first attention is that it is the biggest avoidable cost, a pure network round-trip you can delete, whereas audio capture is partly irreducible (you must wait for the speaker to stop). And that reframing pays off: removing the ASR round-trip alone (220 -> 45, saving 175 ms) brings the total to 1,095 - 175 = 920 ms, already back under the “broken” cliff without touching anything else. The full 520 ms optimum is a 52.5% cut, but the audit’s point is that the first, cheapest move, killing the round-trip, is the one that rescues the experience; the rest is polish toward the more ambitious <800 ms comfort target.

Technical boundaries
Stage overlap, latency tails, cache behavior, network variation, recognition failures, and human response time are absent from this six-point serial sum.

Work the audit first, then check the displayed derivation.

Every number above is taken from the chapter’s own material and re-derived step by step.