Text to Speech vs. Text to Dialogue WebSockets

ElevenLabs bietet zwei WebSocket-Produktfamilien für das Streaming synthetisierter Sprache. Jede Familie hat eine Single-Stream-Variante und eine Multi-Context-Variante, die mehrere unabhängige Streams über eine Verbindung multiplexiert. Sie lösen unterschiedliche Probleme, akzeptieren unterschiedliche Nachrichtenformate und richten sich an unterschiedliche Modelle.

Welchen WebSocket sollte ich verwenden?

Verwenden Sie den Text to Speech (TTS) WebSocket, wenn Sie einfachen Text für eine Stimme pro Verbindung streamen (die Stimme ist in der URL festgelegt) und keine v3-Modelle wie Flash oder Multilingual v2, optionales SSML, Chunk-Zeitpläne oder die Multi-Context-Variante für die Behandlung von Unterbrechungen im Agentenstil benötigen.

Verwenden Sie den Text to Dialogue (TTD) WebSocket, wenn Sie das Dialogverhalten von Eleven v3 benötigen: ausdrucksstarke Wiedergabe, **voice_id pro Chunk **, Gesprächsgrenzen (new_turn) und dieselbe dialogorientierte Pufferung, die serverseitig für v3 verwendet wird.

Verwenden Sie den TTD Multi-Context WebSocket, wenn Sie dasselbe Dialogverhalten von Eleven v3 und mehrere gleichzeitige oder verschachtelte Streams über eine Verbindung benötigen – beispielsweise für einen Conversational Agent, der Dialoge unterbrechen und neu starten muss, ohne jedes Mal einen neuen Socket zu öffnen.

Für Batch- oder HTTP-Streaming von Dialogen (vollständige Anfrage in einem Aufruf) verwenden Sie Dialog erstellen oder Dialog streamen statt eines WebSockets.

Vergleich

	Text to Speech WebSocket	Text to Dialogue WebSocket
API-Referenz	TTS stream-input	TTD WebSocket
URL	`wss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/stream-input`	`wss://api.elevenlabs.io/v1/text-to-dialogue/stream-input`
Stimmauswahl	Eine `voice_id` im Pfad; der gesamte gestreamte Text verwendet diese Stimme	Die erste Nachricht registriert eine oder mehrere `voices` anhand ihrer ID; jeder `inputs[]`-Eintrag enthält eine `voice_id`
Modelle	Flash, Multilingual v2 und andere unterstützte TTS-Modelle. Kein `eleven_v3` oder `eleven_v4` auf diesem Endpunkt.	`model_id` muss mit `eleven_v3` oder `eleven_v4` beginnen (zum Beispiel `eleven_v4` oder `eleven_v4_turbo`)
Erste Client-Nachricht	Mit einem Leerzeichen und optionalen `voice_settings` / `generation_config` initialisieren (siehe Echtzeit-TTS-Leitfaden)	Muss `voices` enthalten (und Anmeldedaten, falls diese nicht bereits über Header oder Query gesendet wurden)
Laufender Text	Einen `text`-String senden (in der Regel mit nachfolgendem Leerzeichen); optional `flush`, `try_trigger_generation` usw.	`inputs` senden: Objekte im Format `{ text, voice_id, new_turn? }`; optional `flush`, `close_socket`, `keep_alive`
Pufferung / Planung	Chunk-Längenplanung und zugehörige TTS-WebSocket-Steuerungen	Der Server puffert, bis genügend Text vorliegt (etwa 40 Zeichen und 8 Wörter), bevor er Audio ausgibt, außer Sie verwenden `flush`
Mehrere Sprecher auf einem Socket	Verwenden Sie den Multi-Context WebSocket für mehrere parallele TTS-Kontexte, nicht für Dialogsemantik mit mehreren Sprechern	Bis zu 10 registrierte Stimmen für `eleven_v4`; `eleven_v4_turbo` erlaubt nur eine registrierte Stimme. Für parallele Dialog -Streams verwenden Sie den TTD Multi-Context WebSocket
Inaktivität	Konfigurierbares `inactivity_timeout` (TTS-WebSocket-Query)	Fest 20 s zwischen Client-Nachrichten, sofern Sie nicht `keep_alive` senden
Gleichzeitigkeit	Nur die aktive Generierungszeit zählt für das Gleichzeitigkeitslimit Ihres Plans; ein inaktiver offener Socket zählt nicht	Jede offene Verbindung belegt für ihre gesamte Laufzeit eine Dialog-Sitzung aus einem separaten Pool; die Generierung über die Verbindung verbraucht keine Standard-Gleichzeitigkeit
Alignment	Optionales `sync_alignment` (TTS-Feldbenennung in der API-Referenz)	Optionales `sync_alignment`; JSON verwendet in Antworten snake_case-Felder (zum Beispiel `is_final`, `char_start_times_ms`)

Wann der TTS WebSocket besser geeignet ist

Sie integrieren bereits Flash oder Multilingual v2 für geringe Latenz oder Sprachabdeckung.
Sie möchten eine Erzählerstimme pro Verbindung und ein einfaches Text-pro-Frame-Protokoll.
Sie benötigen Multi-Context-Orchestrierung für Unterbrechungen und parallele Äußerungen (Multi-Context-Leitfaden).

Eine vollständige Anleitung zum TTS WebSocket finden Sie unter Audio in Echtzeit generieren.

Wann der TTD WebSocket besser geeignet ist

Sie verwenden Eleven v4 für Dialoge (ausdrucksstarke Tags, natürliches Gesprächstempo, Zeilen mit mehreren Sprechern).
Sie streamen geskriptete oder LLM-generierte Dialoge, bei denen die Sprechstimme pro Zeile wechseln kann, ohne eine neue Verbindung zu öffnen.
Sie möchten schrittweise Eingaben im WebSocket-Format mit nur für v4 verfügbarer Dialoggenerierung auf dem Server.

Eine praktische Anleitung finden Sie unter Echtzeit-Text to Dialogue. Protokolldetails finden Sie in der API-Referenz.

Multi-Context WebSockets

Beide Produkte bieten eine Multi-Context-Variante, die mehrere unabhängige Streams über eine einzelne WebSocket-Verbindung multiplexiert. Jeder Kontext wird durch eine vom Client gewählte context_id identifiziert, puffert eigenen Text und gibt Audio-Chunks aus, die mit dieser context_id versehen sind. TTS-Kontexte verwenden die voice_id aus der Verbindungs-URL, während TTD-Kontexte eigene Stimmen und Einstellungen registrieren. Verwenden Sie dieses Format, wenn Sie gleichzeitige oder verschachtelte Generierung mit Unterbrechungsbehandlung benötigen – beispielsweise für einen Sprachagenten, der eine laufende Äußerung abbrechen und eine neue starten muss, ohne die Verbindung zu trennen.

	TTS Multi-Context WebSocket	TTD Multi-Context WebSocket
API-Referenz	TTS multi-stream-input	TTD multi-stream-input
URL	`wss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/multi-stream-input`	`wss://api.elevenlabs.io/v1/text-to-dialogue/multi-stream-input`
Modelle	Flash, Multilingual v2 und andere unterstützte TTS-Modelle. Kein `eleven_v3` oder `eleven_v4`.	`model_id` muss mit `eleven_v3` beginnen (zum Beispiel `eleven_v3` oder `eleven_v3_conversational`). `eleven_v4` wird auf diesem Endpunkt nicht unterstützt.
Kontexte	Mehrere parallele TTS-Kontexte über eine Verbindung	Bis zu 5 gleichzeitige Kontexte pro Verbindung
Stimmen pro Kontext	Eine in der URL festgelegte `voice_id` für jeden Kontext	In der ersten Nachricht für eine `context_id` registriert: 1 für `eleven_v3_conversational`, bis zu 10 für `eleven_v3`
Routing pro Nachricht	Jede Nachricht enthält `context_id`	Jede Nachricht enthält `context_id` (eine Nachricht, die nur `close_socket` enthält, ist die Ausnahme)
Steuernachrichten	`flush`, `close_context`, `close_socket`, `keep_alive` pro Kontext	`flush`, `close_context`, `close_socket`, `keep_alive` pro Kontext
Inaktivität	Konfigurierbares `inactivity_timeout` pro Kontext	Fest 20 s pro Kontext, sofern Sie für diesen Kontext nicht `keep_alive` senden
Authentifizierung	Auf Verbindungsebene (Header, Query oder erste Nachricht)	Auf Verbindungsebene (Header, Query oder erste Nachricht) – nicht pro Kontext

Wann der TTD Multi-Context WebSocket besser geeignet ist

Sie benötigen das Dialogverhalten von Eleven v3 (ausdrucksstarke Wiedergabe, voice_id pro Chunk, Gesprächsgrenzen) und gleichzeitige oder verschachtelte Streams über eine Verbindung.
Sie entwickeln einen Conversational Agent, der Dialoge unterbrechen und neu starten muss, ohne jedes Mal einen neuen Socket zu öffnen.
Sie möchten mehrere unabhängige v3-Dialog-Sitzungen – beispielsweise parallele Szenen oder Sprecher – über eine einzelne authentifizierte Verbindung verteilen.

Für den Single-Stream TTD WebSocket siehe Echtzeit-Text to Dialogue. Für den TTS Multi-Context WebSocket siehe den Multi-Context-WebSocket-Leitfaden. Protokolldetails für den TTD Multi-Context-Endpunkt finden Sie in der API-Referenz.