Open-source Hindi text to speech in 2026: licences, size, streaming and what to test before you choose

Why there is no ranking of open-source Hindi TTS yet

Most "best Hindi TTS" lists rank models on someone's listening impressions, or on speed and quality figures that each model's authors published about their own work. Those figures use different sentences, different hardware and different scoring, so they cannot be lined up against each other. The large Indian-language listening studies of 2026 rank listener preference and accent rather than self-hosted speed, and none was designed to pick a model for your workload; what the published Indic TTS benchmarks measure explains each one.

So this guide does not rank. It compares seven models on properties you can check on their model pages: licence, languages, voices, size, output, streaming and maintenance, each read on 24 October 2026. Then it sets out the test that would rank them for your use, and which failures to look for first.

"Open source" is used loosely here, as it is in most threads. Strictly, these are open-weight models: anyone can download the trained weights, but what you may do with them, and with the audio they produce, depends on the licence. Sonex Labs, which publishes this page, sells its own text-to-speech model, Pāṇini, with native Hindi voices. It is not open source and is not part of this comparison.

The licence decides first

A model whose licence forbids commercial use is out for a business, however good it sounds, so read the licence before any listening test. The seven models fall into three groups.

Languages, voices and model size

After the licence, the next filter is whether a model covers your languages and offers the kind of voice control you need. The table summarises what each model page documents; blank or "not documented" entries mean the page does not say, not that the feature is missing.

Streaming and hardware for live calls

For narration, a model can take its time. For a phone agent, what matters is how soon the first audio arrives, and that depends on whether the model streams, meaning it hands over audio in pieces while it is still generating the rest. A model that returns audio only when the whole sentence is finished makes the caller wait for the full generation time.

Three of the seven document some form of streaming. The parler-tts library has a streamer that starts playback after a set number of decoding steps, and its inference guide claims first audio in less than half a second on a modern GPU with its optimisations (Parler-TTS inference tips). XTTS-v2's documentation describes streaming inference and notes that it is typically slower overall but delivers a first chunk sooner (XTTS documentation). Kokoro's pipeline yields audio one text segment at a time, so playback can start after the first sentence (Kokoro model card).

IndicF5's card documents no streaming mode, Veena lists streaming as future work, and Indic-Speak's card gives a response time before audio starts but describes no streaming mode. Treat every published speed figure, including those above, as the author's claim until you have timed it on your own hardware.

Apart from the small Kokoro, these models expect a GPU for live use, and silent fall-back to the CPU is the most common reason for very slow results in public threads. On a phone line the output is also converted from 24 kHz to 8 kHz, which the guide to 8 kHz phone audio explains. How many simultaneous calls a card can carry is a separate measurement, covered in concurrent calls per 24 GB GPU.

Maintenance and the failures users report

Maintenance matters because Hindi failures get fixed only where someone is still working on the code. IndicF5's GitHub code last changed in September 2025, and both AI4Bharat cards now point users to Indic-Speak, which suggests where the team's effort has moved. The parler-tts library's last commit was in December 2024. Coqui's original repository has had no new commit since early 2024, and development of its toolkit continues in a fork run by the Idiap Research Institute (idiap/coqui-ai-TTS), though the XTTS-v2 weights and their licence are unchanged.

Each model also has open reports of Hindi going wrong, mostly on ordinary input: long paragraphs, numbers or short phrases. The list at the end of this section is a test plan rather than a verdict, because each item is one user's report with their own settings.

Two patterns run through those reports. Long input fails more often than short input, which is why the usual workaround is to split text into sentences before synthesis. Numbers break more often than words, so the suggested fix is a text normaliser that writes ₹1,499 or 4582 out in Hindi words first. How Hindi TTS should read rupees, lakh, crore and dates covers what it must handle.

• IndicF5 skipping or half-saying many Hindi words in long paragraphs, despite good voice cloning, clean reference audio and chunked text (Hugging Face discussion 39).
• IndicF5 producing garbled fragments, different on every run, when a user tried Telugu with the model's own reference prompts (discussion 25).
• IndicF5 failing to load with "Cannot copy out of meta tensor; no data!" on Colab and Kaggle; a user's .to_empty() workaround stopped the error but sometimes gave wrong audio (GitHub issue 10, open).
• IndicF5 turning OTPs, amounts and dates into garbled noise until they were spelt out as words (GitHub issue 31, open).
• Kokoro crashing on a long Hindi passage; another user found the same text generated fine and recommended splitting long text (kokoro issue 241).
• XTTS-v2 adding unintelligible extra sounds to a short Hindi phrase; a project contributor replied that this can happen with short text, and that fine-tuning helps but cannot avoid it completely (coqui-ai/TTS issue 4125).

What you have to test yourself

Once the licence and languages have narrowed the list, only a test on your own sentences and hardware can choose between the survivors. Use the same GPU, driver and library versions for every model, and write them down, because results change with each.

Measure five things. Time to first audio is how long a listener waits before hearing anything. Real-time factor (RTF) is synthesis time divided by the length of the audio produced, so 0.5 means a 4-second sentence takes 2 seconds, and anything at or above 1.0 cannot keep up with speech. Peak VRAM is the most GPU memory the model used. Concurrency is how many streams can run at once while each stays below an RTF of 1.0 and your first-audio target. Number and Hinglish handling is scored right or wrong per item by native listeners.

Decide what matters before you listen. A phone agent needs fast first audio and steady output on short sentences, and can live with less expressive speech. Narration and dubbing can wait longer for each sentence but punish skipped words and odd pacing across a long script. Self-hosting also costs money whether or not anyone is calling, so the break-even guide to self-hosting voice models is worth reading before you commit.

# pip install git+https://github.com/huggingface/parler-tts.git soundfile
import time

import soundfile as sf
import torch
from parler_tts import ParlerTTSForConditionalGeneration
from transformers import AutoTokenizer

assert torch.cuda.is_available(), "No GPU visible: check the runtime type and your CUDA build"
device = "cuda:0"

model = ParlerTTSForConditionalGeneration.from_pretrained("ai4bharat/indic-parler-tts").to(device)
tokenizer = AutoTokenizer.from_pretrained("ai4bharat/indic-parler-tts")
description_tokenizer = AutoTokenizer.from_pretrained(model.config.text_encoder._name_or_path)

prompt = "आपकी EMI पंद्रह तारीख तक भरनी है, यानी अगले गुरुवार तक।"
description = ("A female speaker delivers a slightly expressive and animated speech with a moderate "
               "speed and pitch. The recording is of very high quality, with the speaker's voice "
               "sounding clear and very close up.")

description_ids = description_tokenizer(description, return_tensors="pt").to(device)
prompt_ids = tokenizer(prompt, return_tensors="pt").to(device)

torch.cuda.reset_peak_memory_stats()
torch.cuda.synchronize()
t0 = time.perf_counter()
generation = model.generate(
    input_ids=description_ids.input_ids,
    attention_mask=description_ids.attention_mask,
    prompt_input_ids=prompt_ids.input_ids,
    prompt_attention_mask=prompt_ids.attention_mask,
)
torch.cuda.synchronize()
seconds = time.perf_counter() - t0

audio = generation.cpu().numpy().squeeze()
rate = model.config.sampling_rate
duration = len(audio) / rate
print(f"generated {duration:.2f} s of audio in {seconds:.2f} s, RTF {seconds / duration:.2f}, "
      f"peak VRAM {torch.cuda.max_memory_allocated() / 2**30:.1f} GiB")
sf.write("indic_parler_hi.wav", audio, rate)