https://livekit.io logo
Join Slack
Powered by
in my stop watch latency was 1.4sec , then what is...
# ask-ai
t
in my stop watch latency was 1.4sec , then what is UI Metrics report
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’m responding to your question about what a “UI Metrics report” is and how it relates to your stopwatch latency of 1.4 seconds. Short answer • “UI Metrics report” isn’t a formal LiveKit product name. The closest thing is the visual metrics you see in the LiveKit dashboards — primarily the Agent Insights (Trace) view and the Cloud Analytics dashboard — which break down end-to-end latency into component stages so you can understand where that 1.4s came from. What those UI metrics show (how they relate to your 1.4s) • Trace timelines show stage-by-stage durations such as: ◦ VAD detection / voice end detection ◦ STT (speech-to-text) processing ◦ LLM inference (time to first token) ◦ TTS synthesis and streaming (time to first audio bytes) ◦ Network/transport delays • The dashboard reports metrics like Time To First Token (TTFT) and Time To First Byte (TTFB), which you can add together (plus VAD and network time) to explain your measured 1.4s. How to verify and pinpoint the cause 1. Open the session in the LiveKit Cloud dashboard. 2. Go to Agent Insights and open the Trace view for the turn where you measured 1.4s. 3. Inspect the timestamps/durations for each stage (STT, LLM, TTS, etc.) and see which stage(s) sum to ~1.4s. 4. Optionally check Cloud Analytics for media-level metrics (bandwidth, packet loss, network latency) to rule out transport issues. If you want, I can help next — tell me which of the following you prefer: • I’d like step-by-step help reading a specific Trace entry (please share session/turn details). • Show me how to find TTFT/TTFB in the dashboard. • Help identifying whether STT, LLM, TTS, or network is the likely cause (I’ll need the Trace screenshots or timestamps). Friendly tip: a stopwatch gives a good end-to-end number. The Trace view gives the breakdown so you can target the slowest component. Sources: Streamline troubleshooting with Agent Observability | Streamline troubleshooting with Agent Observability | Streamline troubleshooting with Agent Observability | Agents (Python) | livekit/livekit_composite | DeepWiki | How can I reduce latency in voice agents using STT, TTS and LLM? | LiveKit
t
what metrics report ?
t
Thanks — I’ll clarify. By “metrics report” I mean the visual performance data you can view in the LiveKit UI that explain end-to-end behavior (including latency). The main places you’ll find these reports and the specific metrics they show are: • Agent Insights (Trace view) ◦ Breaks a single call turn into stages with timestamps and durations. ◦ Key metrics shown: VAD/voice-end delay, STT processing time, LLM inference time (time to first token), TTS synthesis/streaming time (time to first byte). ◦ Use this to see exactly which stage(s) add up to your 1.4s stopwatch reading. • Cloud Analytics dashboard ◦ Aggregated and per-session media/connection metrics. ◦ Key metrics: end-to-end latency, round-trip/network latency, packet loss, bandwidth, connection duration. ◦ Use this to spot network or media transport issues that could affect latency. Which one would you like to look at? • If you want a stage-by-stage breakdown for a single turn, say “Trace view” and share the session/turn info or a screenshot. • If you want broader connection-level metrics across sessions, say “Cloud Analytics” and tell me whether you need per-session or aggregate views. I can walk you step-by-step through whichever report you choose.
t
machine response time 1.4sec
t
Thanks — I’m following up about your machine response time of 1.4s and how it maps to the UI metrics. What that 1.4s represents • It’s the end‑to‑end machine response you observed with your stopwatch — the total time from when the system started processing the input to when it returned the machine’s output. • The UI metrics (Agent Insights Trace view and Cloud Analytics) will break that single number into component times (VAD, STT, LLM/TTFT, TTS/TTFB, and network) so you can see which part contributed most. To pinpoint where the 1.4s came from, I can look up the exact metrics for your session. Please provide one of the following: • Session ID and approximate timestamp of the turn (or) • A screenshot of the Trace view or the session timeline showing the turn (or) • Exact stopwatch start/end times and which participant/turn you measured What I’ll do once you share that 1. Open the session’s Agent Insights -> Trace for that turn. 2. Read the stage durations (VAD, STT, LLM TTFT, TTS TTFB, network). 3. Show which stages sum to ~1.4s and highlight the largest contributor. 4. Recommend next steps to reduce latency if you want. Which detail can you share so I can pull the exact metrics for you?
t
after speaking of me , hearing from machine
t
Thanks — I’m responding to your note about “after speaking of me, hearing from machine” and your 1.4s machine response time. What that end-to-end delay means • The delay between you finishing speaking and hearing the machine is the sum of a few stages: ◦ VAD / voice-end detection (time to register you stopped speaking) ◦ STT (speech-to-text) processing ◦ LLM inference (commonly reported as Time To First Token, TTFT) ◦ TTS synthesis and start of audio streaming (commonly reported as Time To First Byte, TTFB) ◦ Network/transport time for the audio to reach your client What the UI shows • In the Agent Insights → Trace view you’ll see the per-turn timeline that lists timestamps and durations for those stages. The trace breaks down the total 1.4s so you can see which stage(s) contributed the most. • In Cloud Analytics you can also check network metrics (latency, packet loss, bandwidth) to rule in/out transport issues. Quick diagnostic step I can help with • The metric that most directly corresponds to “time before you hear the machine” is TTFT + TTFB, plus any VAD and network delays. If you want me to confirm exact numbers for your session, please share one of the following: ◦ Session ID and approximate timestamp of the turn, or ◦ A screenshot of the Trace view for that turn, or ◦ The stopwatch start/end times and which participant/turn you measured Next steps I can take once you share that 1. Pull the Trace for that turn and list each stage’s duration. 2. Show which stages sum to ~1.4s and point out the biggest contributor. 3. Recommend actions to reduce latency if you want (e.g., TTS/LLM optimization, network checks). Which detail can you share so I can pull the exact trace and break down your 1.4s?
2 Views
Open in Slack
PreviousNext
Powered by