टेक्स्ट टू स्पीच बनाम टेक्स्ट टू डायलॉग WebSockets

ElevenLabs सिंथेसाइज़्ड स्पीच को स्ट्रीम करने के लिए WebSocket प्रोडक्ट्स की दो फैमिली देता है। हर फैमिली में single-stream वैरिएंट और multi-context वैरिएंट होता है, जो एक कनेक्शन पर कई स्वतंत्र स्ट्रीम्स को मल्टीप्लेक्स करता है। ये अलग-अलग समस्याएं हल करते हैं, अलग-अलग मैसेज फ़ॉर्मैट स्वीकार करते हैं और अलग-अलग मॉडल्स के लिए बनाए गए हैं।

मुझे कौन-सा WebSocket इस्तेमाल करना चाहिए?

जब आप एक कनेक्शन पर एक वॉइस के लिए सादा टेक्स्ट स्ट्रीम करते हैं (वॉइस URL में तय होती है) और आपको Flash या Multilingual v2 जैसे non-v3 मॉडल्स, वैकल्पिक SSML, chunk schedules या एजेंट-स्टाइल interruption handling के लिए multi-context वैरिएंट चाहिए, तो टेक्स्ट टू स्पीच (TTS) WebSocket इस्तेमाल करें।

जब आपको Eleven v3 डायलॉग व्यवहार चाहिए—expressive delivery, हर chunk के लिए voice_id, turn boundaries (new_turn) और सर्वर पर v3 के लिए इस्तेमाल होने वाली वही डायलॉग-आधारित buffering—तो टेक्स्ट टू डायलॉग (TTD) WebSocket इस्तेमाल करें।

जब आपको वही Eleven v3 डायलॉग व्यवहार और एक ही कनेक्शन पर कई concurrent या interleaved streams चाहिए—जैसे कोई conversational agent जिसे हर बार नया socket खोले बिना डायलॉग को interrupt और restart करना हो—तो TTD multi-context WebSocket इस्तेमाल करें।

batch या HTTP streaming डायलॉग के लिए (एक कॉल में पूरा request), WebSocket की जगह Create dialogue या Stream dialogue इस्तेमाल करें।

तुलना

	टेक्स्ट टू स्पीच WebSocket	टेक्स्ट टू डायलॉग WebSocket
API रेफरेंस	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`
वॉइस चयन	path में एक `voice_id`; सभी स्ट्रीम किया गया टेक्स्ट उसी वॉइस का इस्तेमाल करता है	पहला मैसेज ID के आधार पर एक या अधिक `voices` रजिस्टर करता है; हर `inputs[]` एंट्री में `voice_id` दिया जाता है
मॉडल्स	Flash, Multilingual v2 और अन्य समर्थित TTS मॉडल्स। इस endpoint पर `eleven_v3` या `eleven_v4` नहीं हैं।	`model_id` की शुरुआत `eleven_v3` या `eleven_v4` से होनी चाहिए (उदाहरण के लिए `eleven_v4` या `eleven_v4_turbo`)
पहला client message	एक space और वैकल्पिक `voice_settings` / `generation_config` के साथ initialize करें (realtime TTS गाइड देखें)	इसमें `voices` शामिल होना चाहिए (और credentials, अगर वे headers या query के ज़रिए पहले से नहीं भेजे गए हैं)
आगे का टेक्स्ट	एक `text` string भेजें (आमतौर पर trailing space के साथ); वैकल्पिक `flush`, `try_trigger_generation` आदि।	`inputs` भेजें: `{ text, voice_id, new_turn? }` objects; वैकल्पिक `flush`, `close_socket`, `keep_alive`
Buffering / scheduling	Chunk length schedule और संबंधित TTS WebSocket controls	सर्वर ऑडियो भेजने से पहले पर्याप्त टेक्स्ट आने तक buffer करता है (लगभग 40 characters और 8 words), जब तक आप `flush` न करें
एक socket पर multi-speaker	कई parallel TTS contexts के लिए multi-context WebSocket इस्तेमाल करें, multi-speaker dialogue semantics के लिए नहीं	`eleven_v4` के लिए अधिकतम 10 registered voices; `eleven_v4_turbo` केवल एक registered voice की अनुमति देता है। Parallel dialogue streams के लिए TTD multi-context WebSocket इस्तेमाल करें
निष्क्रियता	कॉन्फ़िगर किया जा सकने वाला `inactivity_timeout` (TTS WebSocket query)	client messages के बीच 20s तय हैं, जब तक आप `keep_alive` न भेजें
Concurrency	केवल active generation समय आपके प्लान की concurrency limit में गिना जाता है; निष्क्रिय खुला socket नहीं गिना जाता	हर खुला कनेक्शन अपनी पूरी अवधि के लिए अलग pool से एक dialogue session रखता है; कनेक्शन पर generation standard concurrency का उपयोग नहीं करती
Alignment	वैकल्पिक `sync_alignment` (API रेफरेंस में TTS field naming)	वैकल्पिक `sync_alignment`; JSON responses में snake_case fields इस्तेमाल करता है (उदाहरण के लिए `is_final`, `char_start_times_ms`)

जब TTS WebSocket बेहतर विकल्प है

आप latency या language coverage के लिए पहले से Flash या Multilingual v2 इंटीग्रेट कर चुके हैं।
आप हर कनेक्शन पर एक narrator voice और आसान text-per-frame protocol चाहते हैं।
आपको barge-in और parallel utterances के लिए multi-context orchestration चाहिए (multi-context गाइड)।

TTS WebSocket की पूरी जानकारी के लिए Generate audio in real-time देखें।

जब TTD WebSocket बेहतर विकल्प है

आप Eleven v4 डायलॉग (expressive tags, conversational pacing, multi-speaker lines) का लक्ष्य रखते हैं।
आप scripted या LLM-generated dialogue स्ट्रीम करते हैं, जिसमें बोलने वाली वॉइस हर लाइन के लिए बदल सकती है, बिना नया कनेक्शन खोले।
आप सर्वर पर v4-only डायलॉग generation के साथ WebSocket-जैसा incremental input चाहते हैं।

व्यावहारिक जानकारी के लिए Realtime Text to Dialogue देखें। प्रोटोकॉल की जानकारी API रेफरेंस में है।

Multi-context WebSockets

दोनों प्रोडक्ट्स में multi-context वैरिएंट है, जो एक WebSocket कनेक्शन पर कई स्वतंत्र streams को multiplex करता है। हर context की पहचान client द्वारा चुने गए context_id से होती है, वह अपना टेक्स्ट खुद buffer करता है और उस context_id से टैग किए गए ऑडियो chunks भेजता है। TTS contexts कनेक्शन URL से voice_id साझा करते हैं, जबकि TTD contexts अपनी वॉइसेस और settings रजिस्टर करते हैं। जब आपको interruption handling के साथ concurrent या interleaved generation चाहिए, तब यह फ़ॉर्मैट इस्तेमाल करें—जैसे कोई voice agent जिसे कनेक्शन बंद किए बिना चल रहे utterance को रद्द करके नया शुरू करना हो।

	TTS multi-context WebSocket	TTD multi-context WebSocket
API रेफरेंस	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`
मॉडल्स	Flash, Multilingual v2 और अन्य समर्थित TTS मॉडल्स। `eleven_v3` या `eleven_v4` नहीं।	`model_id` की शुरुआत `eleven_v3` से होनी चाहिए (उदाहरण के लिए `eleven_v3` या `eleven_v3_conversational`)। इस endpoint पर `eleven_v4` समर्थित नहीं है।
Contexts	एक कनेक्शन पर कई parallel TTS contexts	हर कनेक्शन पर अधिकतम 5 simultaneous contexts
हर context के लिए वॉइसेस	हर context के लिए URL में एक `voice_id` तय होती है	`context_id` के लिए पहले मैसेज में रजिस्टर होती हैं: `eleven_v3_conversational` के लिए 1, `eleven_v3` के लिए अधिकतम 10
Per-message routing	हर मैसेज में `context_id` शामिल होता है	हर मैसेज में `context_id` शामिल होता है (`close_socket` वाला अकेला मैसेज अपवाद है)
Control messages	हर context के लिए `flush`, `close_context`, `close_socket`, `keep_alive`	हर context के लिए `flush`, `close_context`, `close_socket`, `keep_alive`
निष्क्रियता	हर context के लिए कॉन्फ़िगर किया जा सकने वाला `inactivity_timeout`	हर context के लिए 20s तय, जब तक आप उस context के लिए `keep_alive` न भेजें
Authentication	कनेक्शन स्तर पर (header, query या पहला message)	कनेक्शन स्तर पर (header, query या पहला message) — हर context के लिए नहीं

जब TTD multi-context WebSocket बेहतर विकल्प है

आपको Eleven v3 डायलॉग व्यवहार (expressive delivery, हर chunk के लिए voice_id, turn boundaries) और एक कनेक्शन पर concurrent या interleaved streams चाहिए।
आप एक conversational agent बना रहे हैं, जिसे हर बार नया socket खोले बिना डायलॉग को interrupt और restart करना हो।
आप एक authenticated कनेक्शन पर कई स्वतंत्र v3 dialogue sessions—जैसे parallel scenes या speakers—चलाना चाहते हैं।

Single-stream TTD WebSocket के लिए Realtime Text to Dialogue देखें। TTS multi-context WebSocket के लिए Multi-context WebSocket गाइड देखें। TTD multi-context endpoint के प्रोटोकॉल की जानकारी API रेफरेंस में है।