How do I implement verbalize_time for the voice ag...
# ask-ai
p
How do I implement verbalize_time for the voice agent? should it be a new tool for LLM or can I do it at the TTS layer? how will it impact the latency?
t
Thanks for reaching out, Shriniket. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — you’re asking whether to implement
verbalize_time
as an LLM tool or inside the TTS layer, and how each affects latency. Quick answer up front: • Use the TTS layer for minimal latency and deterministic current-time announcements. • Use an LLM tool only if you need the model to reason about time (e.g., “three business days from now,” relative times, or context-aware phrasing). Short rationale and implementation notes • TTS-layer approach (recommended for most cases) ◦ How: Insert a placeholder (e.g.,
[TIME]
) in the LLM output or detect time tokens just before synthesis, then replace with a formatted spoken string (like “The time is 2:35 PM”) or SSML. ◦ Latency: Low — no extra LLM round-trip. Only TTS synthesis time applies (fastest path for real-time agents). ◦ When to pick: Real-time clocks, periodic announcements, or deterministic phrasing. • LLM-tool approach ◦ How: Expose
verbalize_time
as a callable tool/function the model can invoke to generate a natural-language time string, then feed that output to TTS. ◦ Latency: Higher — adds LLM inference time and tool-invocation processing (time-to-first-token + model reasoning). Use this when the model must decide to call the tool or compute relative/complex times. ◦ When to pick: Context-aware responses, complex temporal reasoning, or when phrasing must be dynamically composed by the model. Practical suggestions • If you choose TTS-layer: format timestamps centrally (single function) so phrasing/locale/SSML is consistent and easy to change. • If you need some reasoning but want lower latency: let the LLM output a lightweight placeholder plus optional relative phrasing (e.g., “in two hours — [TIME]”), then have a small local helper convert relative times to absolute text before TTS. • Test latency end-to-end (agent decision -> text -> TTS audio) in your environment to measure actual TTFT and TTS times. If you want, tell me: • whether you need relative/complex time reasoning or only current-time announcements, and • your TTS provider (or if you plan to use SSML), and I’ll provide a small example tailored to that setup. Sources: Tool definition and use | LiveKit docs | Agent speech and audio | LiveKit docs | Cartesia TTS plugin guide | LiveKit docs
p
I've already added in the prompt like this: 10:30 AM → "सुबह साढ़े दस बजे" but it doesn't work reliably, it works some time, but some time it goes like दस बज के तीस मिनट बजे which is not the right way of saying the time in hindi. You already get 10:30 AM from RAG so llm have that info and for TTS I'm using Cartesia
t
Thanks — I hear you: the LLM prompt mapping is producing inconsistent Hindi renderings (e.g., correct "सुबह साढ़े दस बजे" vs. awkward "दस बज के तीस मिनट बजे"). Since you already receive a precise time (10:30 AM) via RAG and you use Cartesia TTS, the most reliable approach is to convert the time into a deterministic, locale-correct Hindi string before TTS (TTS-layer or small preprocessing helper). This avoids LLM variability and keeps latency low. What to do (recommended) 1. Preprocess times into canonical Hindi phrases before sending text to Cartesia. ◦ Replace placeholders like
[TIME]
with a formatted string produced by a small, deterministic function. ◦ This can live in the TTS pipeline or a lightweight middleware right after RAG/LLM output. 1. Use explicit rules for common patterns (examples) ◦ Exact hour (10:00 AM) -> "सुबह दस बजे" ◦ Half hour (10:30 AM) -> "सुबह साढ़े दस बजे" ◦ Quarter past (10:15 AM) -> "सुबह सवा दस बजे" ◦ Quarter to (9:45 AM) -> "दस बजे से चौथे मिनट पहले" — but prefer "सवा चार" patterns for common usage (see below) ◦ Minutes 1–29 -> "X बजे Y मिनट" only when no idiomatic phrase exists ◦ Prefer idiomatic Hindi for halves/quarters and common colloquial forms: ▪︎ :15 -> "सवा [hour]" (e.g., 10:15 -> "सवा दस बजे" or "सवा दस") ▪︎ :30 -> "साढ़े [hour]" (e.g., 10:30 -> "साढ़े दस बजे") ▪︎ :45 -> "पौने [next_hour]" (e.g., 9:45 -> "पौने दस बजे") ◦ Use period-of-day prefixes: रात/सुबह/दोपहर/शाम based on hour ranges (e.g., 5–11 -> सुबह, 12–15 -> दोपहर, 16–19 -> शाम, 20–4 -> रात) 1. Example deterministic function (pseudo)
Copy code
def verbalize_hindi(dt):
    h = dt.hour % 12 or 12
    m = dt.minute
    period = choose_period(dt.hour)  # returns 'सुबह','दोपहर','शाम','रात'
    if m == 0:
        return f"{period} {h} बजे"
    if m == 30:
        return f"{period} साढ़े {h} बजे"
    if m == 15:
        return f"{period} सवा {h} बजे"
    if m == 45:
        next_h = (h % 12) + 1
        return f"{period} पौने {next_h} बजे"
    return f"{period} {h} बजकर {m} मिनट"  # fallback
(Adjust wording to your preferred register and remove "बजे" if Cartesia voices prefer shorter phrases.) 1. Cartesia-specific notes • Cartesia supports SSML; use it to control prosody/pause around the time phrase for clearer speech. • Send the fully formed Hindi string to Cartesia (avoid leaving time-formatting to the LLM). • This keeps latency minimal: only your small formatting function + Cartesia TTS synthesis time. 1. Handling mixed cases • If you need context-aware phrasing (e.g., “in two hours” or business-day logic), compute that programmatically and pass the resolved absolute time into the same deterministic formatter before TTS. • If you must let the LLM craft the phrase, constrain it tightly with a function tool that returns the preformatted Hindi string (but expect higher latency). If you want, I can: • Provide a ready-to-copy implementation in your language (Python/Node) for Cartesia integration and SSML wrapping. • Add locale rules for formal vs. colloquial Hindi phrasing. Which would help you most: a full code example in Python or Node?