Understanding Latency

There is no single latency number for a live speech system.

What users experience as "latency" is the result of several different stages.

The latency pipeline

A simplified real-time pipeline looks like:

speaker
  ↓
audio capture
  ↓
network transport
  ↓
speech recognition
  ↓
context processing
  ↓
optional translation
  ↓
application rendering

Each stage contributes to the final experience.

First-result latency

The time between incoming speech and the first usable recognition result.

Lower first-result latency generally makes an interface feel more responsive.

However, extremely early results may contain greater uncertainty.

Stabilization latency

The time required before evolving speech becomes sufficiently stable for a particular use.

This is different from first-result latency.

For example:

300 ms → first interpretation appears
900 ms → surrounding context resolves ambiguity
1.2 s → segment becomes stable

These numbers are illustrative only.

The important point is that responsiveness and stability are different measurements.

Translation latency

Live translation introduces another dependency.

Translation quality improves when more linguistic context is available, while live experiences require output before the full conversation is known.

This creates another latency-quality tradeoff.

LansonAI therefore treats live translation as a streaming context problem rather than simply translating a completed transcript.

Measure the user experience

For live applications, useful latency measurements should reflect what the user actually experiences.

Depending on the application, this may include:

• time to first readable text
• time to stable text
• time to translated text
• correction frequency
• visible reflow
• end-to-end interaction latency

Optimizing only one number can make another part of the experience worse.