Laxman [12:49 PM] Hey even I'm checking the late...
# ask-ai
t
Laxman [12:49 PM] Hey even I'm checking the latency purpose in livekit website ,it was giving 2000ms latency but i'm cross checking with stopwatch it shows every response taking 2.5 -3.5 seconds How metrics was evaluted I'm not understanding
t
Thanks for reaching out, Laxman. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I understand you’re comparing the LiveKit “OVERALL” latency (≈2116ms) shown in the demo UI to your stopwatch measurements (2.5–3.5s) and want to know how the metric is calculated and why they differ. I’ll explain what the UI reports and what your stopwatch is likely measuring. What the LiveKit UI latency numbers represent • The UI’s latencies are internal, end-to-end processing times measured inside the voice agent pipeline, from when the user stops speaking (end of turn) to when the agent begins producing audio. The UI breaks this down as: ◦ SPEECH-TO-TEXT: time to transcribe audio to text (e.g., 266ms) ◦ END OF TURN: time to detect the user has finished speaking (e.g., 365ms) ◦ LLM: time to get the first token from the language model (TTFT) (e.g., 1245ms) ◦ TEXT-TO-SPEECH: time to get the first audio byte from TTS (TTFB) (e.g., 246ms) • OVERALL is the sum of those internal stages (example: 266 + 365 + 1245 + 246 ≈ 2116ms). Why your stopwatch shows 2.5–3.5 seconds • Your manual timing likely captures user-perceived latency, which includes things the UI metric does not: ◦ The duration of your spoken utterance (time spent speaking). ◦ Any silent pause or endpointing delay before the system detects the end of your turn. ◦ Network transmission or buffering outside the agent’s measured pipeline. ◦ Client-side playback startup latency (audio playback on your device). • Example: If you speak for 0.7s, pause 0.3s for endpointing, plus the agent’s internal ~2.1s, your stopwatch would read ~3.1s even though the UI reports ~2.1s. How to measure so results align • To match the UI’s reported metric, start timing at the end of your speech (when you stop speaking) and stop timing when the agent begins producing audio (first audible byte). That should closely match the OVERALL value. If you want, I can help further by: • Walking through a measurement checklist you can follow to reproduce the UI metric. • Helping identify whether endpointing settings, network delays, or client audio startup are contributing to your extra 0.4–1.4s. • Reviewing screenshots or the exact steps you used with the stopwatch so I can point out which component(s) add extra time. Which would you like to try next? Sources: examples/frontdesk | livekit/livekit_composite | DeepWiki | LLM Metrics | LiveKit Documentation | TTS Metrics | LiveKit Documentation