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

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

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

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

Text to Dialogue (TTD) WebSocket का इस्तेमाल करें, जब आपको Eleven v3 डायलॉग व्यवहार चाहिए: एक्सप्रेसिव डिलीवरी, हर चंक के लिए voice_id, टर्न बाउंड्रीज़ (new_turn), और सर्वर पर v3 के लिए इस्तेमाल होने वाली वही डायलॉग-आधारित बफ़रिंग।

बैच या HTTP स्ट्रीमिंग डायलॉग के लिए (एक कॉल में पूरा अनुरोध), 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`
वॉइस चयन	पाथ में एक `voice_id`; सारा स्ट्रीम किया गया टेक्स्ट उसी वॉइस का इस्तेमाल करता है	पहला मैसेज ID से एक या ज़्यादा `voices` रजिस्टर करता है; हर `inputs[]` एंट्री में एक `voice_id` होता है
मॉडल्स	Flash, Multilingual v2 और अन्य समर्थित TTS मॉडल्स। इस एंडपॉइंट पर `eleven_v3` नहीं ।	`model_id` की शुरुआत `eleven_v3` से होनी चाहिए (उदाहरण के लिए `eleven_v3` या `eleven_v3_conversational`)
पहला क्लाइंट मैसेज	स्पेस और वैकल्पिक `voice_settings` / `generation_config` के साथ इनिशियलाइज़ करें (रियलटाइम TTS गाइड देखें)	इसमें `voices` शामिल होना चाहिए (और क्रेडेंशियल्स, अगर वे पहले से हेडर्स या क्वेरी के ज़रिए नहीं भेजे गए हैं)
जारी टेक्स्ट	`text` स्ट्रिंग भेजें (आमतौर पर अंत में स्पेस के साथ); वैकल्पिक `flush`, `try_trigger_generation` आदि।	`inputs` भेजें: `{ text, voice_id, new_turn? }` ऑब्जेक्ट्स; वैकल्पिक `flush`, `close_socket`, `keep_alive`
बफ़रिंग / शेड्यूलिंग	चंक लंबाई शेड्यूल और संबंधित TTS WebSocket कंट्रोल्स	सर्वर ऑडियो भेजने से पहले पर्याप्त टेक्स्ट आने तक बफ़र करता है (लगभग 40 कैरेक्टर और 8 शब्द), जब तक आप `flush` न करें
एक सॉकेट पर कई स्पीकर	कई समानांतर TTS कॉन्टेक्स्ट्स के लिए multi-context WebSocket इस्तेमाल करें, मल्टी-स्पीकर डायलॉग सेमांटिक्स के लिए नहीं	`eleven_v3` के लिए अधिकतम 10 रजिस्टर्ड वॉइस; `eleven_v3_conversational` केवल एक रजिस्टर्ड वॉइस की अनुमति देता है
निष्क्रियता	कॉन्फ़िगर किया जा सकने वाला `inactivity_timeout` (TTS WebSocket क्वेरी)	क्लाइंट मैसेज के बीच 20 सेकंड तय हैं, जब तक आप `keep_alive` न भेजें
कन्करेंसी	केवल एक्टिव जनरेशन समय आपके प्लान की कन्करेंसी सीमा में गिना जाता है; निष्क्रिय खुला सॉकेट नहीं गिना जाता	हर खुला कनेक्शन अपनी पूरी अवधि के लिए अलग पूल से एक डायलॉग सेशन रखता है; कनेक्शन पर जनरेशन स्टैंडर्ड कन्करेंसी का उपयोग नहीं करती
अलाइनमेंट	वैकल्पिक `sync_alignment` (API रेफरेंस में TTS फ़ील्ड नामकरण)	वैकल्पिक `sync_alignment`; JSON रिस्पॉन्स में snake_case फ़ील्ड इस्तेमाल होते हैं (उदाहरण के लिए `is_final`, `char_start_times_ms`)

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

आपने लेटेंसी या भाषा कवरेज के लिए पहले से Flash या Multilingual v2 इंटीग्रेट किया हुआ है।
आपको हर कनेक्शन पर एक नैरेटर वॉइस और आसान टेक्स्ट-पर-फ़्रेम प्रोटोकॉल चाहिए।
आपको बार्ज-इन और समानांतर कथनों के लिए multi-context ऑर्केस्ट्रेशन चाहिए (multi-context गाइड)।

TTS WebSocket की पूरी जानकारी के लिए रियल-टाइम में ऑडियो जनरेट करें देखें।

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

आप Eleven v3 डायलॉग को टारगेट कर रहे हैं (एक्सप्रेसिव टैग्स, बातचीत की गति, मल्टी-स्पीकर लाइनें)।
आप स्क्रिप्टेड या LLM-जनरेटेड डायलॉग स्ट्रीम करते हैं, जिसमें बोलने वाली वॉइस हर लाइन में बदल सकती है, बिना नया कनेक्शन खोले।
आपको सर्वर पर केवल v3 डायलॉग जनरेशन के साथ WebSocket-आकार का इंक्रीमेंटल इनपुट चाहिए।

व्यावहारिक जानकारी के लिए रियलटाइम टेक्स्ट टू डायलॉग देखें। प्रोटोकॉल की जानकारी API रेफरेंस में है।