Where dictation latency actually comes from

How to read the demo

• The cloud path includes network handshake, upload time, recognition time, and service overhead.
• The local path keeps speech recognition on-device and only adds optional extra time if you ask for an external text rewrite.
• The point is not to produce one magic number. It is to show which pieces of the path disappear when audio does not have to leave the machine.

What the model assumes

The interactive uses simple, explicit assumptions: network round-trip time, upload bandwidth, a rough cloud transcription speed, and a local finalization step for the last chunk of speech. That makes it honest. Real providers differ, but the structure of the delay stays the same.

This mirrors how streaming speech systems are typically documented: audio is chunked, sent over a live stream, processed incrementally, and finalized after speech ends. Larger network delays and slower uploads still have to be paid for somewhere.

Why this matters in actual use

• For a one-line note on fast fiber, cloud latency can feel acceptable.
• For repeated short dictation bursts during normal work, every extra second compounds into friction.
• For bad hotel Wi-Fi, trains, or offline situations, the difference stops being about speed and becomes about whether the workflow works at all.

References

• MDN: Round Trip Time
• MDN: Understanding latency
• Google Cloud: Transcribe audio from streaming input
• Google Cloud: Best practices to provide data to Speech-to-Text