https://livekit.io logo
Join Slack
Powered by
```total_latency = eou.end_of_utterance_delay + ll...
# ask-ai
e
Copy code
total_latency = eou.end_of_utterance_delay + llm.ttft + tts.ttfb
the above formula is given by livekit to calculate latency I have the following below questions: 1. on_user_turn_completed_delay is the agent callback initiated after the end_of_utterance_delay, so it should be included in the latency calculation process? 2. there is a param of e2e_latency in observability feature, what does it actually represent (time from agent callback initiated till audio generation starting?) 3. if the above 2 questions are true then the formula of end_of_utterance_delay + on_user_turn_completed_delay + e2_latency, wouldnt that give a more accurate picture of latency of livekit integration?
t
Thanks for reaching out, Harsh. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I'll answer each of your three questions about the latency formula and metrics. 1) on_user_turn_completed_delay — should it be included? • Yes. 
on_user_turn_completed_delay
runs after 
end_of_utterance_delay
and before LLM inference, so it contributes to perceived end-to-end latency. If your 
on_user_turn_completed
callback does non-trivial work (RAG, DB calls, etc.), include it in your latency calculation. 2) what does e2e_latency represent? • There is no documented metric named 
e2e_latency
. The observability metrics that are defined are 
end_of_utterance_delay
, 
on_user_turn_completed_delay
, 
llm.ttft
, and 
tts.ttfb
. The meaning of 
e2e_latency
cannot be confirmed. 3) would adding them produce a more accurate total latency? • Yes — a more complete formula is:
Copy code
accurate_total_latency =
    end_of_utterance_delay +
    on_user_turn_completed_delay +
    llm.ttft +
    tts.ttfb
This captures VAD-to-turn completion, any user callback processing, time-to-first-LLM-token, and time-to-first-TTS-audio. If 
e2e_latency
in your system is intended to equal 
llm.ttft + tts.ttfb
, then using a separate 
e2e_latency
term could double-count those parts — rely on the specific metric definitions above. Would you like help mapping these metrics to the observability output you’re seeing (example logs/events or metric names)? Sources: Observability data hooks | LiveKit docs
e
sorry, its e2eLatency not e2e_latency , have added an example of Attributes of an Assitant message from Agent Insights in observability feature {"chat.item":{"message":{"id":"item_17097259d94b","role":"ASSISTANT","content":[{"text":"<sample_text>"}],"metrics":{"startedSpeakingAt":"2025-12-11T160027.891Z","stoppedSpeakingAt":"2025-12-11T160032.719Z","llmNodeTtft":0.5360258970003997,"ttsNodeTtfb":1.0313006979995407,"e2eLatency":2.6007907390594482},"createdAt":"2025-12-11T160026.334Z"}},"room_id":"RoomId","job_id":"JobId","logger.name":"chat_history"}
t
Thanks — I’m responding to your clarification about 
e2eLatency
and the sample observability attributes. • 
e2eLatency
meaning: In Agent Insights 
e2eLatency
is the end‑to‑end latency measured from the moment the user turn is detected as complete to when the agent begins speaking. It is effectively the sum of endpointing (end_of_utterance) time plus the model and TTS startup times. • How 
e2eLatency
relates to your other metrics:
Copy code
e2eLatency ≈ end_of_utterance_delay + llm.ttft + tts.ttfb
In your sample: • 
llmNodeTtft
= 0.536 s • 
ttsNodeTtfb
= 1.031 s • 
e2eLatency
= 2.601 s → remaining ≈ 1.034 s is attributed to endpointing (which includes any 
on_user_turn_completed
processing when present). • Should you include 
on_user_turn_completed_delay
in your latency formula? Yes — if your 
on_user_turn_completed
callback does non-trivial work (RAG, DB calls, network calls, etc.), that time is part of the perceived latency and should be included for an accurate measurement. Note that 
on_user_turn_completed
time is represented inside EOUMetrics/endpointing in observability when available. • Recommended “most accurate” formula to track in your integration:
Copy code
accurate_total_latency =
    end_of_utterance_delay
    + on_user_turn_completed_delay
    + llm.ttft
    + tts.ttfb
If 
e2eLatency
is already present in your observability export, it gives you a ready end‑to‑end number (but it aggregates endpointing + LLM + TTS). Use the breakdown above to isolate which stage is the bottleneck. Would you like help correlating these fields with specific logs or a sample session trace so we can pinpoint where that ~1.03s in your sample comes from? Sources: Agents (Python) | livekit/livekit_composite | DeepWiki | How does end-of-utterance detection work in conversations? | Observability data hooks | LiveKit docs | examples/voice_agents | livekit/livekit_composite | DeepWiki | Agents (Node.js) | livekit/livekit_composite | DeepWiki
2 Views
Open in Slack
PreviousNext
Powered by