AssemblyAI details Python WebSocket workflow for streaming text to speech
AssemblyAI published a Python tutorial on streaming text to speech over WebSocket connections, framing it as a workflow for voice agents rather than a simple file-generation task. The company said the approach is designed to handle three live-call problems that saved audio files do not solve: LLM replies that are still being generated, caller interruptions, and long-running sessions that must stay healthy throughout a conversation.
Evidence and context
According to the tutorial published on Wed, 28 Oct 2026, the AssemblyAI Text-to-Speech API supports three routes: HTTP for one-shot synthesis, WebSocket for a single session across a conversation, and an OpenAI-compatible speech endpoint. The post says the Python SDK gained text-to-speech support in release 1.8.2 and shows how to install it with pip, set ASSEMBLYAI_API_KEY, and call TextToSpeech.synthesize() to produce a WAV file. It also states that billing is based on billed_characters at $15 per 1M characters, and that the API supports six languages: English, Spanish, French, German, Italian and Portuguese.
The tutorial then moves to TTSSession, which AssemblyAI presents as the preferred interface for a voice agent. In the example code, the session is opened once per conversation, each sentence is spoken as a separate request, and the sample reads the sample rate back from the Begin frame rather than assuming it. The company says WebSocket output is raw 16-bit little-endian PCM in mono, typically at 24 kHz unless configured otherwise, and notes that phone applications often require 8 kHz mu-law instead.
AssemblyAI also details a token-streaming pattern for chaining LLM output into speech. Its documentation says generate() appends incoming text, flush() closes the current request, and audio(flush_id) yields the synthesized audio for that request. The company warns against flushing every token because it makes speech choppy and can hit control-frame limits, and it says barge-in should be handled by cancel() so the LLM text stops, queued requests are dropped, and any buffered local audio is cleared.
The post further notes two session-management limits: idle sessions close after two minutes without any frame in either direction, and a session can last at most one hour. AssemblyAI says keep_alive() restarts the idle timer without changing anything else, and that developers should open replacement sessions before the one-hour deadline if a call runs longer. It also says a single generate() call accepts up to 2,000 characters.
As background, recent TTS tooling updates in the wider Python ecosystem include Coqui-TTS 0.28.0 on 2026-10-19, Piper 1.8.0 on 2026-09-04 with Thai phonemization, and Piper 1.7.0 on 2026-08-15 with Japanese phonemization through OpenJTalk. Those releases are separate from AssemblyAI’s post, but they show ongoing activity in both local and API-based text-to-speech tooling. The AssemblyAI tutorial itself does not supply independent benchmark data for latency or quality, and its performance claims should be read as vendor statements rather than independently verified measurements.