> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inworld.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Generating Naturally Sounding Speech

> How to get natural, expressive speech out of Inworld TTS — voice selection, writing for the ear, steering, context, normalization, and LLM prompting.

This guide covers how to get the most natural, expressive speech out of Inworld TTS — from choosing the right voice to writing text that speaks well, steering delivery, and prompting an LLM whose output feeds into TTS. For latency techniques, see the [Latency](/tts/best-practices/latency) guide.

## Start from the right voice

Different voices suit different applications: for a meditation app, pick a steady, calm voice; for an encouraging fitness coach, pick an expressive, excited one. Choose a voice that matches the emotional range you're looking for — no amount of text engineering will make the wrong voice sound right.

<Note>
  By default, the model is designed to closely reproduce the voice sample it was given. The delivery you hear — energy, pace, warmth — mirrors the delivery in the sample, so an [instant voice clone](/tts/instant-voice-cloning) made from a calm, flat recording will speak calmly and flatly no matter what the text says. If you need an energetic voice, clone from an energetic sample. [Professional voice cloning](/tts/professional-voice-cloning) trains on much more audio, so a PVC voice captures a broader expressive range than any single sample can.
</Note>

For recording tips and sample scripts, see [Voice Cloning best practices](/tts/best-practices/voice-cloning). To push a voice's delivery beyond its sample for a specific line or turn, use [steering](#steer-the-delivery-on-inworld-tts-2) on `inworld-tts-2`.

## Write for the ear

Speech text is not display text. The way you write shapes the delivery more than any parameter:

1. **Pay attention to punctuation** — Use exclamation points (!) to make the voice more emphatic and excited. Use periods to insert natural pauses, and commas for shorter breaks. Where possible, include punctuation at the end of every sentence.
2. **Capitalize for emphasis** — Emphasize specific words by capitalizing them: "We NEED a real vacation" stresses *need*, while "We need a REAL vacation" stresses *real*. Capitalizing individual syllables works too: "AbsoLUTEly". Alternatively, wrap a word in single asterisks (`*word*`).
   <Warning>
     Use single asterisks only (`*word*`). Double asterisks (`**word**`) will cause TTS to read the asterisk characters aloud instead of emphasizing the word.
   </Warning>
3. **Vary sentence length** — Short sentences speed things up and add urgency; longer sentences slow the pace for calm, measured delivery.
4. **Add filler words for conversational speech** — Natural human conversation is full of `uh`, `um`, `well`, `like`, and `you know`. The models generate the requested text as-is, so if you want conversational imperfection, write it in: "Uh, I'm not uh too sure about that." Skip fillers for formal applications like narration or customer support.
5. **Use pause controls for precise pauses** — When punctuation isn't enough, add SSML break tags like `<break time="1s" />`. See [Pause Controls](/tts/capabilities/pause-controls).

## Add non-verbal sounds

Non-verbal tags insert organic, human sounds — a laugh, a sigh, a sharp breath — exactly where you place them:

> I told him what happened, and he just \[laugh] couldn't believe it!

They work on **both** `inworld-tts-2` and `inworld-tts-2-flash`. The most reliable ones are `[laugh]` `[breathe]` `[clear throat]` `[sigh]` `[cough]` `[yawn]`; see the [full list of recognized sounds](/tts/capabilities/steering#recognized-sounds). Place them inline where the sound naturally belongs — each tag produces one occurrence and doesn't change how the surrounding words are spoken.

## Steer the delivery on `inworld-tts-2`

On `inworld-tts-2`, [steering](/tts/capabilities/steering) lets you direct delivery in natural language — emotion, pacing, volume, and vocal style — with instruction tags placed before the text they apply to, or a request-level `instruction` field:

> \[say excitedly with a high pitch and fast pace] I have great news. Your package has arrived!

Two things to keep in mind:

* **Don't overuse it.** The model already reproduces the character of the voice sample; steering is for the moments where the delivery should *change*. A tag stays in force until you change it or write `[reset]`, so one tag at the start covers a whole passage — re-tagging every sentence gives the model less continuity to work with and can make delivery uneven.
* **Match the instruction to the text.** `[sound sad]` on celebratory text sends contradictory signals and degrades output quality.

<Note>
  `inworld-tts-2-flash` does not support steering — instruction tags and the `instruction` field are ignored, though [non-verbal](#add-non-verbal-sounds) tags like `[laugh]` work as usual.
</Note>

## Give the model conversation context

Speech doesn't happen in a vacuum: how *"Yeah."* should sound depends entirely on what came before it. Use the [`synthesisContext`](/api-reference/ttsAPI/texttospeech/synthesize-speech-stream#body-synthesis-context) field to pass the text of previous requests from the same session or conversation, in the order they were synthesized:

```json theme={"system"}
{
  "text": "Yeah, that works for me.",
  "voiceId": "Ashley",
  "modelId": "inworld-tts-2",
  "synthesisContext": {
    "previousRequests": [
      { "text": "Hey, are you still free to meet on Thursday?" },
      { "text": "We could do the morning instead if that's easier." }
    ]
  }
}
```

This gives the model additional context and can improve the quality of the generation — especially for short or ambiguous input where the text alone doesn't determine the right intonation.

## Speak the right language

Set the [`language`](/api-reference/ttsAPI/texttospeech/synthesize-speech#body-language) field for the most consistent results when generating cross-lingual audio, and [localize the voice](/tts/capabilities/multilingual#voice-localization) for native-sounding speech in the target language. See [Language Support](/tts/capabilities/multilingual) for details.

## Normalize complex text

Text like phone numbers, dollar amounts, and dates often isn't written the way it's spoken. Inworld TTS includes an optional **normalization** step that expands these into their spoken forms before synthesis:

* **Phone numbers**: "(123)456-7891" → "one two three, four five six, seven eight nine one"
* **Dates**: 5/6/2025 → "may sixth twenty twenty five"
* **Times**: "12:55 PM" → "twelve fifty-five PM"
* **Emails**: [test@example.com](mailto:test@example.com) → "test at example dot com"
* **Monetary values**: \$5,342.29 → "five thousand three hundred and forty two dollars and twenty nine cents"
* **Symbols**: 2+2=4 → "two plus two equals four"

Toggle it with the [`applyTextNormalization`](/api-reference/ttsAPI/texttospeech/synthesize-speech-stream#body-apply-text-normalization) parameter:

* `ON` — always normalize
* `OFF` — skip normalization entirely
* `APPLY_TEXT_NORMALIZATION_UNSPECIFIED` (default) — TTS decides per-request

<Note>
  Server-side normalization is available for many of the [supported languages](/tts/capabilities/multilingual#supported-languages). It's language-specific, not locale-specific (e.g., `en-US` and `en-GB` are normalized the same way). For languages where normalization doesn't apply, expand the text yourself before sending it.
</Note>

<Note>
  Normalization adds slight latency to each TTS request. For latency-sensitive applications, expand the text in your LLM prompt or application instead and set `applyTextNormalization` to `OFF`.
</Note>

**With normalization on** (recommended for most cases), standard expansions are handled for you; you only need to guide edge cases that normalization may not cover — ambiguous dates (`01/02/2025` could be January 2nd or February 1st), domain-specific abbreviations (`RDS`, `k8s`, `HIPAA`), and uncommon acronyms.

**With normalization off**, your application or LLM must handle *all* text expansion — no digits, no symbols, no shorthand. Use this when you need full control over how text is spoken, or when your domain has pronunciation requirements that conflict with the default expansion rules.

| Raw Text           | Normalization Produces                                              | You Should Produce (Normalization Off)                    |
| ------------------ | ------------------------------------------------------------------- | --------------------------------------------------------- |
| `12/04/2025`       | "twelve oh four twenty twenty-five"                                 | "december fourth, twenty twenty-five"                     |
| `(555) 123-4567`   | "five five five, one two three, four five six seven"                | "five five five, one two three, four five six seven"      |
| `$1,249.99`        | "one thousand two hundred forty-nine dollars and ninety-nine cents" | "twelve hundred forty-nine dollars and ninety-nine cents" |
| `3:45 PM`          | "three forty-five PM"                                               | "three forty-five PM"                                     |
| `test@example.com` | "test at example dot com"                                           | "test at example dot com"                                 |
| `2 + 2 = 4`        | "two plus two equals four"                                          | "two plus two equals four"                                |

## Tune the delivery mode

For `inworld-tts-2`, use the [`deliveryMode`](/api-reference/ttsAPI/texttospeech/synthesize-speech#body-delivery-mode) field to control the trade-off between stability and variability. `STABLE` produces more consistent, predictable output (best when the output must closely match the input). `CREATIVE` produces more varied speech with greater emotional range (useful for creative use cases like barks or demo clips). `BALANCED` (the default) sits in between.

## Prompting your LLM

When an LLM generates text that gets fed into TTS, the default output often sounds flat and unnatural. LLMs tend to produce clean, well-formatted text, but clean text isn't the same as *speakable* text: dates stay as `12/04`, acronyms aren't expanded, and there are no cues for emphasis, pauses, or emotion. This section shows what to add to your LLM system prompt so its output follows the practices above.

<Note>
  On `inworld-tts-2`, you can go further and have the LLM embed [steering](/tts/capabilities/steering) tags directly in its output. See [Prompting for TTS-2](/tts/best-practices/prompting-for-tts-2) for steering-aware prompt templates.
</Note>

### Emphasis

**Prompt snippet:**

```
Use asterisks (*word*) to emphasize key words in your response — focus on
prices, deadlines, action items, or any word the listener needs to catch.
Use punctuation to convey tone:
- Exclamation marks for excitement or urgency
- Ellipsis (...) for trailing off, hesitation, or leaving a thought unfinished
  Example: "I thought it would work, but..."
```

**Before (no emphasis guidance):**

> I think this is a really important point and you should consider it carefully.

**After (with emphasis guidance):**

> I think this is a \*really\* important point, and you should consider it \*carefully\*.

### Pronunciation

For uncommon words like brand names, proper nouns, and technical terms, Inworld TTS supports inline [IPA phoneme notation](/tts/capabilities/custom-pronunciation). You can provide a pronunciation dictionary in your system prompt that the LLM substitutes inline.

**Prompt snippet:**

```
When you use any of the following words, replace them with their IPA pronunciation
inline using slash notation:
- "Crete" → /kriːt/
- "Yosemite" → /joʊˈsɛmɪti/
- "Nguyen" → /ŋwɪən/
- "Acai" → /ɑːsɑːˈiː/
```

**Before (no pronunciation guidance):**

> You should visit Crete for your honeymoon.

**After (with IPA substitution):**

> You should visit /kriːt/ for your honeymoon.

Use standard English IPA phonemes only (not CMU dictionary or ARPAbet) — see [Custom Pronunciation](/tts/capabilities/custom-pronunciation) for finding the right phonemes. Alternatively, run a string parser over the LLM output that substitutes entries from your pronunciation dictionary before passing text to TTS — useful when the same dictionary must apply consistently across multiple LLM providers.

### Pauses and pacing

**Prompt snippet:**

```
Control pacing through punctuation and sentence structure:
- Use periods to separate thoughts and create pauses
- Use commas for shorter breaks within sentences
- Use ellipsis (...) to create a lingering pause or beat
- Use short sentences for emphasis and urgency
- Use longer sentences for calm, measured delivery
```

**Before (flat pacing):**

> The results are in and we exceeded our target by 40 percent so this is the best quarter we have ever had.

**After (with pacing guidance):**

> The results are in. We exceeded our target... by \*forty percent\*. This is the \*best\* quarter we have ever had.

### Conversational naturalness

**Prompt snippet:**

```
To sound natural and conversational, include filler words where a human speaker
would naturally use them:
- "uh" and "um" for thinking moments
- "well" and "so" for transitions
- "like" and "you know" for casual emphasis

Example: "So, uh, I was thinking we could, you know, try a different approach."
```

<Warning>
  Filler words are best for casual, conversational use cases. Skip them for formal applications like news reading, professional narration, or customer support.
</Warning>

### Output length

LLMs tend to be verbose. A detailed paragraph may read well on screen, but sounds unnatural and exhausting when spoken aloud. Keeping responses short produces better-sounding speech and reduces latency.

A good default is to ask your LLM to respond in 1–2 sentences unless the user's query specifically demands a longer answer. Use sentences as your length unit, not words or characters — LLMs operate on tokens, so word and character counts are unreliable constraints.

**Prompt snippet:**

```
Keep your responses to 1-2 sentences unless the user's question specifically
requires a longer explanation. Prefer concise, direct answers.
```

### Example prompt templates

Below are complete, copyable system prompt blocks tailored for common use cases. Each template combines the techniques above into a ready-to-use prompt.

<Tabs>
  <Tab title="Companion / Conversational">
    Use this template for chatbots, AI companions, virtual friends, and other informal conversational applications.

    ```
    ## Speech Output Rules

    Your responses will be converted to speech using TTS. Follow these
    rules to produce natural, expressive spoken output:

    ### Expressiveness
    - Use *asterisks* to emphasize key words
    - Use exclamation marks for excitement, ellipsis for trailing off
    - Insert non-verbal tags where organic: [laugh], [sigh], [breathe]

    ### Naturalness
    - Include filler words (uh, um, well, like, you know) where a human would naturally pause
    - Vary sentence length for natural rhythm
    - Use contractions (don't, can't, I'm, we're) instead of formal forms

    ### Pronunciation
    - Replace uncommon proper nouns with IPA: e.g., /kriːt/ for Crete
    [Add your pronunciation dictionary here]

    ### Text Formatting
    - Write numbers in spoken form: "twenty-three" not "23"
    - Write dates in spoken form: "march fifteenth" not "3/15"
    - Never use markdown formatting, bullet points, or structured text
    - Never use emojis or special characters
    - Write everything as natural spoken sentences
    ```
  </Tab>

  <Tab title="Support / Sales">
    Use this template for customer support agents, sales assistants, and other professional conversational applications.

    ```
    ## Speech Output Rules

    Your responses will be converted to speech using TTS. Follow these
    rules to produce clear, professional spoken output:

    ### Clarity
    - Use *asterisks* sparingly to emphasize critical information (prices, deadlines, action items)
    - Use short, clear sentences for important details
    - Use periods to separate distinct points

    ### Professionalism
    - Do NOT use filler words (uh, um, like, you know)
    - Do NOT use non-verbal tags (laugh, sigh, etc.) — maintain professionalism
    - Maintain a warm but professional tone
    - Use contractions naturally (don't, we'll, you're)

    ### Numbers and Data
    - Speak account numbers digit by digit: "one two three four five six" not "123456"
    - Speak prices naturally: "forty-nine ninety-nine" or "forty-nine dollars and ninety-nine cents"
    - Speak dates fully: "january fifteenth, twenty twenty-five" not "1/15/2025"
    - Speak phone numbers in groups: "five five five, one two three, four five six seven"

    ### Pronunciation
    - Replace product names and brand terms with IPA where needed
    [Add your pronunciation dictionary here]

    ### Text Formatting
    - Never use markdown formatting, bullet points, or structured text
    - Never use emojis or special characters
    - Write everything as natural spoken sentences
    ```
  </Tab>

  <Tab title="Dev Tools / Technical">
    Use this template for coding assistants, documentation readers, technical narrators, and developer-facing tools.

    ```
    ## Speech Output Rules

    Your responses will be converted to speech using TTS. Follow these
    rules to produce accurate, well-paced technical speech:

    ### Technical Accuracy
    - Spell out acronyms on first use: "AWS, or Amazon Web Services"
    - For common acronyms after first use, speak them as words if pronounceable
      (e.g., "NASA") or spell them out if not (e.g., "A-P-I")
    - Speak URLs by component: "github dot com slash inworld dash AI"
    - Speak code identifiers in plain English: "the getUserName function" not "getUserName()"
    - Speak version numbers naturally: "version three point two" not "v3.2"

    ### Pronunciation
    - Replace technical proper nouns with IPA:
    [Add your pronunciation dictionary here, e.g.:]
    - "Kubernetes" → /kuːbərˈnɛtiːz/
    - "Nginx" → /ˈɛndʒɪnɛks/
    - "PostgreSQL" → /ˈpoʊstɡrɛsˌkjuːˈɛl/

    ### Pacing
    - Use measured, even pacing. Avoid rushing through technical content.
    - Insert periods before key technical terms to create natural pauses
    - Keep sentences moderate length
    - Do NOT use filler words (uh, um, like, you know)

    ### Text Formatting
    - Write all numbers in spoken form: "forty-two" not "42"
    - Never use markdown formatting, bullet points, or code blocks
    - Never use emojis or special characters
    - Write everything as natural spoken sentences
    ```
  </Tab>
</Tabs>

### Tips for iterating

* **Test with the TTS Playground**: Use the [TTS Playground](/tts/tts-playground) to quickly hear how your LLM output sounds when synthesized. Paste in sample outputs and iterate on your prompt until the speech quality meets your needs.
* **Tune LLM temperature for consistency**: Lower temperatures produce more consistent output that follows your formatting rules reliably. Higher temperatures can produce more expressive text but may ignore specific instructions. Start around `0.7` and adjust based on results.
* **Iterate on your pronunciation dictionary**: Start with a small set of terms and expand as you discover mispronunciations during testing. Ask an LLM to generate IPA for new terms.

## Next Steps

<CardGroup cols={3}>
  <Card title="Prompting for TTS-2" icon="wand-magic-sparkles" href="/tts/best-practices/prompting-for-tts-2">
    Have your LLM embed steering tags for expressive, directed speech on inworld-tts-2.
  </Card>

  <Card title="Latency" icon="gauge-high" href="/tts/best-practices/latency">
    Streaming, chunking, and connection techniques for the fastest time to first audio.
  </Card>

  <Card title="Voice Cloning" icon="microphone" href="/tts/best-practices/voice-cloning">
    Best practices for producing high-quality voice clones.
  </Card>
</CardGroup>
