टेक्स्ट टू स्पीच API इंटीग्रेशन: स्ट्रीमिंग, बैचिंग, रिट्राई

टेक्स्ट टू स्पीच API को इंटीग्रेट करना आसान है… बस पहले कुछ ठोस फैसले लेने होते हैं: कौन-सा ट्रांसफर मोड इस्तेमाल करना है, मॉडल और आउटपुट फ़ॉर्मैट कैसे चुनना है, स्ट्रीम कैसे करना है, अपनी concurrency limit पार किए बिना बड़े वॉल्यूम को कैसे प्रोसेस करना है, कैश और रीट्राई कैसे करना है ताकि आप एक ही ऑडियो को रेंडर करने के लिए दो बार भुगतान न करें, और किसी दूसरे प्रदाता के मुकाबले time-to-first-byte को कैसे बेंचमार्क करना है।

टेक्स्ट टू स्पीच API इंटीग्रेशन में आपकी मदद के लिए, हमने इन सभी आर्किटेक्चरल फैसलों और उनके सही तरीकों को समझाया है। यह गाइड आपको ElevenLabs टेक्स्ट टू स्पीच API को इंटीग्रेट और स्केल करने में मदद करेगी। इसमें ऐसे कोड स्निपेट्स हैं जिन्हें आप शुरू करने के लिए सीधे प्रोडक्शन में पेस्ट कर सकते हैं।

यहाँ बताए गए कॉन्सेप्ट्स की विस्तृत जानकारी के लिए, हमारी ऑडियो स्ट्रीमिंग को समझना, लेटेंसी ऑप्टिमाइज़ करना, और ElevenLabs मॉडल ओवरव्यू गाइड्स देखें। 

सारांश

• एक ElevenLabs टेक्स्ट टू स्पीच API endpoint है, जिसे आप तीन तरीकों से एक्सेस कर सकते हैं: batch convert, HTTP stream और stream-input WebSocket।
• HTTP पर हर in-flight request आपकी concurrency limit में गिनी जाती है, जबकि WebSocket पर सिर्फ़ सक्रिय generation गिनी जाती है।
• अपनी parallelism को अपनी plan limit से थोड़ा नीचे रखें और ऑडियो आउटपुट को प्रभावित करने वाले हर parameter का hash कैश करें, ताकि एक ही टेक्स्ट के लिए कभी दो बार बिल न हो।
• concurrency की सीमा तक पहुँचने से पहले धीमा होने के लिए 429 और 5xx को exponential backoff और full jitter के साथ रीट्राई करें।

टेक्स्ट टू स्पीच API इंटीग्रेट करने के तीन तरीके

टेक्स्ट टू स्पीच का एक endpoint है, लेकिन उसे इंटीग्रेट करने का तरीका आपकी लेटेंसी, जटिलता और लागत तय करता है। 

एक ही POST /v1/text-to-speech/{voice_id} कॉल तीन रूपों में काम करती है, जिनमें से हर एक थोड़ा अलग काम के लिए उपयुक्त है। टेक्स्ट टू स्पीच API को इंटीग्रेट करने के तीनों तरीकों का विवरण यह है:

• Batch (convert) सबसे आसान इंटीग्रेशन है: आप एक request भेजते हैं और बदले में एक ऑडियो response पाते हैं। यह सबसे कम जटिल विकल्प है और इसमें time-to-first-audio सबसे अधिक होता है, क्योंकि कोई भी byte वापस आने से पहले पूरी क्लिप synthesize होती है।
• HTTP streaming (stream) request को वही रखता है, लेकिन response को chunks में भेजता है: आप path में /stream जोड़ते हैं, stream method कॉल करते हैं और ऑडियो chunked response के रूप में वापस आता है। कोड लगभग एक जैसा रहता है, लेकिन महसूस होने वाली लेटेंसी बहुत कम होती है।
• WebSocket (stream-input) एक persistent connection बनाए रखता है: आप टेक्स्ट को क्रमशः भेजते हैं और साथ-साथ ऑडियो chunks पाते हैं। यह interactive agents और LLM के tokens बनते समय, वाक्य पूरा होने से पहले ही उसके आउटपुट को speech में भेजने के लिए बनाया गया है।

स्ट्रीमिंग मॉडल को ऑडियो तेज़ी से जनरेट नहीं कराती; inference time में कोई बदलाव नहीं होता। स्ट्रीमिंग सिर्फ़ यह बदलती है कि आपको पहला chunk कब मिलता है: वह पूरी क्लिप तैयार होने से पहले भेज दिया जाता है, इसलिए कुल काम समान होने पर भी यूज़र को इंतज़ार कम लगता है।

Batch बनाम streaming बनाम WebSocket निर्णय तालिका

इन तीन तरीकों में से चुनते समय आपको कई बातों पर ध्यान देना चाहिए।

संक्षिप्त गाइड: offline rendering के लिए batch चुनें, यूज़र के इंतज़ार वाले ज्ञात टेक्स्ट के लिए HTTP streaming, और agents व live LLM-to-speech के लिए WebSocket चुनें। 

नीचे की तालिका उन पहलुओं में trade-offs बताती है जो स्केल पर महत्वपूर्ण होते हैं।

HTTP पर, चाहे batch हो या streaming, हर in-flight request अपनी पूरी अवधि के लिए आपके plan की concurrency limit में गिनी जाती है। WebSocket पर सिर्फ़ वह समय गिना जाता है जब मॉडल सक्रिय रूप से ऑडियो जनरेट कर रहा हो; खुला लेकिन idle socket लगभग कोई लागत नहीं जोड़ता।

एक कैस्केडेड वॉइस एजेंट के लिए, जो पूरी बातचीत के दौरान connection खुला रखता है लेकिन सिर्फ़ agent की बारी में ऑडियो जनरेट करता है, यह अंतर बड़ा है। agents बनाते समय WebSocket इस्तेमाल करने का यही मुख्य कारण है। पूरा protocol realtime टेक्स्ट टू स्पीच WebSocket गाइड में दिया गया है।

मॉडल और आउटपुट फ़ॉर्मैट चुनना

आपके TTS API इंटीग्रेशन से लौटने वाले ऑडियो को दो विकल्प तय करते हैं। पहला, मॉडल, जो क्वालिटी और स्पीड तय करता है। दूसरा, आउटपुट फ़ॉर्मैट, जो container, bitrate और sample rate तय करता है।

शुरुआत से इन दोनों को सही रखने पर, लेटेंसी और टेलीफोनी compatibility जैसी आगे की सभी चीज़ें सही बैठती हैं।

मॉडल

हम कई टेक्स्ट टू स्पीच मॉडल देते हैं। इन्हें सबसे अच्छे से सबसे कम अच्छे के क्रम में रैंक नहीं किया गया है; हर मॉडल अलग trade-offs करता है।

ध्यान दें कि ~75ms का आँकड़ा representative conditions में मॉडल inference का है, जिसमें नेटवर्क और एप्लिकेशन लेटेंसी शामिल नहीं है। लंबे input और लोड में यह बढ़ता है। हमेशा अपने एप्लिकेशन से मापें, किसी benchmark नंबर से नहीं।

Flash मॉडल छोटे होते हैं और inference time कम करने के लिए अधिक आक्रामक approximations इस्तेमाल करते हैं। Eleven v4 और Multilingual v2 बड़े मॉडल हैं, जो बेहतर आउटपुट बनाने के लिए हर character पर ज़्यादा समय लेते हैं।

real-time या agent path के लिए eleven_flash_v2_5 इस्तेमाल करें; यह सबसे कम लेटेंसी वाला multilingual विकल्प है। narration, ऑडियोबुक्स, या marketing voiceover के लिए, स्थिर और उच्च fidelity चाहिए तो eleven_multilingual_v2 इस्तेमाल करें, या अधिकतम expressiveness और emotional range चाहिए तो eleven_v4 चुनें। 

जब pronunciation महत्वपूर्ण हो, जैसे फोन नंबर, तारीख या मुद्रा के लिए, टेक्स्ट के API तक पहुँचने से पहले अपने एप्लिकेशन में नंबर normalization करें। जिस तरह बोलवाना चाहते हैं, उसे लिखकर दें। 

खुद normalization करने से सभी मॉडलों में pronunciation अनुमानित रहता है और ऐसे model-specific defaults पर निर्भरता नहीं रहती जो बदल सकते हैं।

आउटपुट फ़ॉर्मैट

output_format parameter, वापस मिलने वाले ऑडियो का container, sample rate और bitrate नियंत्रित करता है। जिन values का आप सबसे अधिक इस्तेमाल करेंगे:

वॉइस सेटिंग्स

नीचे दी गई सेटिंग्स जनरेट हुई speech के delivery तरीके को नियंत्रित करती हैं:

• स्थिरता: consistency और expressiveness को नियंत्रित करती है। कम values ज़्यादा विविध और expressive speech देती हैं, जबकि ज़्यादा values अधिक स्थिर और अनुमानित delivery देती हैं।
• समानता बूस्ट: नियंत्रित करता है कि आउटपुट reference voice को कितनी बारीकी से follow करे।
• स्टाइल: बढ़ाने पर वॉइस के स्वाभाविक बोलने के स्टाइल को अधिक उभारता है।
• स्पीकर बूस्ट इस्तेमाल करें: थोड़ी लेटेंसी की कीमत पर मूल speaker से समानता बढ़ाता है।
• स्पीड: 1.0 के default के आसपास delivery की गति बदलता है।

इन सेटिंग्स में Stability का आमतौर पर perceived quality पर सबसे अधिक असर होता है। कम values अधिक expressive लेकिन कम consistent आउटपुट बनाती हैं, जबकि ज़्यादा values consistency और predictability को प्राथमिकता देती हैं।

वॉइस चुनते समय, सबसे कम लेटेंसी वाला संयोजन Flash के साथ Instant वॉइस क्लोन या default voice है; Professional Voice Clones की आवाज़ बेहतरीन होती है, लेकिन उनमें हर generation पर अतिरिक्त overhead जुड़ता है, जिसे ध्यान में रखना चाहिए।

इस गाइड में sample voice id JBFqnCBsd6RMkjVDRZzb (George) है।

स्ट्रीमिंग इंटीग्रेशन (HTTP और WebSocket)

इस सेक्शन में हम टेक्स्ट टू स्पीच API इंटीग्रेशन के व्यावहारिक मूल भाग को कवर करते हैं। इसमें SDK इंस्टॉल करना, stream खोलना और आते ही ऑडियो को consume करना शामिल है। HTTP path ज़्यादातर web और app playback के लिए है, जबकि WebSocket path agents और live LLM output के लिए है।

इन दोनों paths में यह माना गया है कि आपने नीचे दिया ElevenLabs client initialize कर लिया है।

npm install @elevenlabs/elevenlabs-js

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({
  apiKey: process.env.ELEVENLABS_API_KEY,
});

streaming path एक stream खोलता है और आते ही chunks को consume करता है। voiceId पहला positional argument है, जिसके बाद camelCase keys (modelId, outputFormat, voiceSettings) वाला options object आता है:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text,
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
  voiceSettings: { stability: 0, similarityBoost: 1.0, style: 0, useSpeakerBoost: true, speed: 1.0 },
});

for await (const chunk of stream) {
  // chunk is a Buffer; feed it to the player as it arrives
}

WebSocket variant के लिए wss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/stream-input से connect करें, अपनी voice settings और शुरुआत में एक space वाला पहला message भेजें, फिर उपलब्ध होते ही text messages भेजें और उन JSON frames को पढ़ें जिनके audio field में base64-encoded chunks होते हैं।

high throughput के लिए batching और concurrency limits

high-throughput इंटीग्रेशन concurrency द्वारा नियंत्रित होता है, यानी एक ही समय पर ऑडियो जनरेट करने वाली requests की संख्या। हर plan में प्रति model family एक limit होती है। 

हर plan में अलग concurrency limit शामिल होती है:

• मुफ़्त: 4 concurrent Flash requests।
• स्टार्टर: 6 concurrent Flash requests।
• क्रिएटर: 10 concurrent Flash requests।
• प्रो: 20 concurrent Flash requests।
• Scale और Business: 30 concurrent Flash requests, जबकि Enterprise limits कस्टम होती हैं।

Multilingual v2 की limits ऊपर दी गई limits की लगभग आधी हैं।

एक bounded pool एक समय में चलने वाली requests की संख्या सीमित करके इसे कम करता है:

// Set MAX_CONCURRENCY at or below your plan's Flash concurrency limit.
const MAX_CONCURRENCY = 8;

async function synthMany(texts: string[]): Promise<Buffer[]> {
  const results: Buffer[] = [];
  for (let i = 0; i < texts.length; i += MAX_CONCURRENCY) {
    const batch = texts.slice(i, i + MAX_CONCURRENCY);
    results.push(...(await Promise.all(batch.map(eachSingleRequest)))); // never more than MAX_CONCURRENCY in flight
  }
  return results;

MAX_CONCURRENCY को अपनी plan limit के ठीक बराबर रखने के बजाय उससे थोड़ा कम रखें। यह अतिरिक्त जगह उसी key को शेयर करने वाले दूसरे traffic को संभालती है और आपको उस threshold से नीचे रखती है जहाँ 429 मिलता है।

character limits और लंबे टेक्स्ट को विभाजित करना

हर मॉडल एक request में स्वीकार किए जाने वाले characters की संख्या सीमित करता है। किसी भी long-form इंटीग्रेशन को टेक्स्ट विभाजित करके ऑडियो को फिर से जोड़ना होता है। 

हर मॉडल की प्रति-request character limits ये हैं:

• Flash v2.5: प्रति request अधिकतम 40,000 characters स्वीकार करता है।
• Flash v2: प्रति request अधिकतम 30,000 characters स्वीकार करता है।
• Multilingual v2: प्रति request अधिकतम 10,000 characters स्वीकार करता है।
• Eleven v3: प्रति request अधिकतम 5,000 characters स्वीकार करता है।
• Eleven v4: प्रति request अधिकतम 10,000 characters स्वीकार करता है।

इससे लंबा टेक्स्ट कई requests में बाँटना होगा। वाक्य boundaries पर विभाजित करने की कोशिश करें, ताकि chunks के बीच की seam पर prosody बनी रहे।

function splitText(text: string, maxChars: number): string[] {
  const sentences = text.trim().split(/(?<=[.!?])\s+/);
  const chunks: string[] = [];
  let current = "";
  for (let sentence of sentences) {
    if (current.length + sentence.length + 1 > maxChars) {
      if (current) chunks.push(current.trim());
      // A single sentence longer than the limit is hard-split.
      while (sentence.length > maxChars) {
        chunks.push(sentence.slice(0, maxChars));
        sentence = sentence.slice(maxChars);
      }
      current = sentence;
    } else {
      current = `${current} ${sentence}`.trim();
    }
  }
  if (current) chunks.push(current.trim());
  return chunks;
}

chunks को क्रम से रेंडर करें और ऑडियो को concatenate करें। ऐसी long-form narration में जहाँ हर chunk स्वतंत्र हो, दोनों हिस्से सीधे मिल जाते हैं: splitText के आउटपुट को ऊपर वाले bounded pool में दें और बाकी काम उसे करने दें।

कैशिंग और idempotency

टेक्स्ट टू स्पीच आउटपुट इतना deterministic है कि एक ही टेक्स्ट को उसी voice, model और settings के साथ फिर से रेंडर करना बेकार है। ऑडियो को प्रभावित करने वाले inputs के hash को key बनाकर परिणाम कैश करें, और यही key retries में idempotency token के रूप में भी काम करती है।

दोनों काम ऐसे करें।

import { createHash } from "node:crypto";

function cacheKey(text: string, voiceId: string, modelId: string,
                  outputFormat: string, settings: object): string {
  // Every parameter that changes the audio must be in the key.
  const payload = JSON.stringify({ text, voiceId, modelId, outputFormat, settings });
  return createHash("sha256").update(payload).digest("hex");
}

async function cachedSynth(text: string, voiceId: string, modelId: string,
                           outputFormat: string, settings: object): Promise<Buffer> {
  const key = cacheKey(text, voiceId, modelId, outputFormat, settings);
  const cached = await cacheGet(key);          // e.g. read from disk or S3
  if (cached) return cached;

  const audio = await elevenlabs.textToSpeech.convert(voiceId, { text, modelId, outputFormat });
  await cachePut(key, audio);                   // store the bytes under the key
  return audio;
}

इसे काम करने योग्य बनाने वाला नियम यह है कि ऑडियो बदलने वाला हर parameter key में होना चाहिए, जिसमें outputFormat और voice settings शामिल हैं। सही तरीके से करने पर यही key idempotency token के रूप में भी काम करती है। जब client पहले से सफल हुई request को रीट्राई करता है, तो दोबारा जनरेट करने के बजाय आप cached bytes लौटाते हैं।

error handling और rate limits (429s)

production client को backoff और jitter वाली retries चाहिए, साथ ही status code के अनुसार अलग handling भी चाहिए, क्योंकि कुछ failures रीट्राई करने लायक होते हैं और कुछ नहीं। 

नीचे की तालिका हर status के लिए सही action बताती है, और यह सेक्शन समझाता है कि 429 hard wall के बजाय soft limit क्यों है।

429 कोई hard wall नहीं है, और इसका mechanism जानना मददगार है। concurrency limit पार होने पर requests को पहले priority के अनुसार queue किया जाता है, जिससे आमतौर पर लगभग 50ms जुड़ते हैं। उसके बाद भी capacity पार होने पर ही आपको 429 मिलता है। 

response में current-concurrent-requests और maximum-concurrent-requests headers भी होते हैं, जो उपलब्ध live headroom बताते हैं। इसलिए आप उन्हें पढ़कर limit तक पहुँचने से पहले धीमा हो सकते हैं।

const RETRYABLE = new Set([429, 500, 502, 503, 504]);

async function synthWithRetry(text: string, voiceId: string, maxRetries = 5): Promise<Buffer> {
  let delay = 500; // ms, base for exponential backoff
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await elevenlabs.textToSpeech.convert(voiceId, {
        text, modelId: "eleven_flash_v2_5", outputFormat: "mp3_44100_128",
      });
    } catch (err: any) {
      const status = err.statusCode;
      // 401/422 and exhausted retries are not recoverable here.
      if (!RETRYABLE.has(status) || attempt === maxRetries) throw err;
      // Exponential backoff with full jitter.
      await new Promise((r) => setTimeout(r, Math.random() * delay));
      delay = Math.min(delay * 2, 8000);
    }
  }
  throw new Error("unreachable");
}

जब आपको बेहतर retry behavior नहीं, बल्कि अधिक headroom चाहिए, तो अपना plan upgrade करें। Enterprise ग्राहक अपने account manager के ज़रिए अधिक limits का अनुरोध कर सकते हैं।

लेटेंसी और time-to-first-byte की बेंचमार्किंग

लेटेंसी आपके region, input और मौजूदा load पर निर्भर करती है। इसका मतलब है कि भरोसे लायक लेटेंसी नंबर सिर्फ़ वही है जिसे आपने अपने environment से मापा हो। 

यह सेक्शन Flash streaming endpoint के लिए time-to-first-byte (TTFB) देता है और इसे इस तरह बनाया गया है कि आप इसी harness को दूसरे प्रदाता पर लगाकर समान परिस्थितियों में तुलना कर सकें।

इसे methodology मानें, प्रकाशित परिणाम नहीं। कोई एक run किसी चीज़ की गारंटी नहीं है। 

टेक्स्ट टू स्पीच API इंटीग्रेशन की लेटेंसी बेंचमार्क करते समय ये कुछ महत्वपूर्ण बातें हैं:

• network round-trip शामिल करें: TTFB आपकी भौगोलिक स्थिति और प्रदाता के निकटतम cluster पर निर्भर करता है, इसलिए टेस्ट वहाँ से चलाएँ जहाँ आपके servers आमतौर पर चलते हैं।
• warmup run को हटाएँ: cold connection पर पहली request धीमी होती है और आपके नंबरों को बिगाड़ सकती है।
• inputs को स्थिर रखें: input length, voice, model और load, सभी परिणाम बदलते हैं, इसलिए सभी providers के लिए इन्हें एक जैसा रखें।
• distribution रिपोर्ट करें: हर run में नंबर बदलते हैं, इसलिए एक value के बजाय median और p95 प्रकाशित करें।

इन बातों को ध्यान में रखते हुए, अब आप बेंचमार्क करने के लिए तैयार हैं।

const TEXT = "This is a fixed benchmark sentence used for every provider.";

async function measureElevenLabs(): Promise<number> {
  const start = performance.now();
  const res = await fetch(
    "https://api.elevenlabs.io/v1/text-to-speech/JBFqnCBsd6RMkjVDRZzb/stream?output_format=mp3_44100_128",
    {
      method: "POST",
      headers: { "xi-api-key": process.env.ELEVENLABS_API_KEY!, "Content-Type": "application/json" },
      body: JSON.stringify({ text: TEXT, model_id: "eleven_flash_v2_5" }),
    },
  );
  for await (const _ of res.body!) {
    return performance.now() - start; // first chunk received
  }
  throw new Error("no audio returned");
}

किसी दूसरे प्रदाता से तुलना करने के लिए, उसी shape वाला एक function लिखें। फिर दोनों को एक छोटे runner से चलाएँ, जो एक warm-up call हटा दे, एक-दूसरे से न टकराने के लिए अंतराल पर लिए गए ~20 timed samples ले और milliseconds में median व p95 बताए।

निष्पक्ष तुलना के लिए variables को नियंत्रित करना ज़रूरी है। 

दोनों providers को एक ही machine और network से चलाएँ, बेहतर होगा कि उस region के server से चलाएँ जहाँ आप वास्तव में deploy करते हैं, न कि residential broadband वाले laptop से। एक ही input text इस्तेमाल करें और ऑडियो छोटा रखें, ताकि generation length के बजाय model inference नंबर पर हावी रहे। कई runs का median और p95 रिपोर्ट करें, क्योंकि एक अकेला measurement noise है। 

ध्यान रखें कि public internet पर TTFB में 20-200ms का network round-trip शामिल होता है, जिसका मॉडल से कोई संबंध नहीं होता। हम North America, Europe और Southeast Asia के clusters से सेवा देते हैं और निकटतम cluster पर route करते हैं, इसलिए अपने test client को उसी अनुसार co-locate करें; वरना आप मुख्य रूप से data center की दूरी को बेंचमार्क कर रहे होंगे।

अपने टेक्स्ट टू स्पीच API इंटीग्रेशन के लिए मुख्य बातें

एक production टेक्स्ट टू स्पीच API इंटीग्रेशन कुछ महत्वपूर्ण फैसलों पर निर्भर करता है।

अगर आप इन्हें सही कर लेते हैं, तो बाकी सब सही बैठ जाता है:

• काम के आधार पर मॉडल चुनें: हर interactive काम के लिए Flash v2.5 और ऐसे offline rendering के लिए, जहाँ लेटेंसी कम मायने रखती है, Multilingual v2 जैसा high-fidelity मॉडल या Eleven v4 इस्तेमाल करें।
• जब भी यूज़र इंतज़ार कर रहा हो, stream करें: ज्ञात टेक्स्ट के लिए HTTP streaming और agents के लिए WebSocket इस्तेमाल करें, ताकि idle time आपकी concurrency budget में न गिना जाए।
• अपनी parallelism को plan limit तक सीमित रखें: concurrent requests को अपनी plan limit से थोड़ा नीचे रखें और ऑडियो आउटपुट को प्रभावित करने वाले हर parameter के hash पर कैश करें, ताकि उसी ऑडियो के लिए कभी दो बार बिल न हो।
• 429 और 5xx को exponential backoff और full jitter के साथ रीट्राई करें: 429 और 5xx मिलने पर full jitter के साथ back off करें और concurrency headers देखकर जानें कि आप limit के कितने करीब हैं।
• लंबे टेक्स्ट को वाक्य boundaries पर बाँटें: हर मॉडल की character limit के भीतर वाक्य boundaries पर बाँटें, ताकि स्वराघात seam पर बनी रहे।

और गहराई से जानने के लिए स्ट्रीमिंग कैसे करें, ऑडियो स्ट्रीमिंग कॉन्सेप्ट, ऑथेंटिकेशन, और client-side इस्तेमाल के लिए single-use tokens देखें।

ElevenAPI के साथ अपना टेक्स्ट टू स्पीच इंटीग्रेशन बनाएँ

इस गाइड को पढ़ने के बाद आपके पास production टेक्स्ट टू स्पीच API इंटीग्रेशन के लिए ज़रूरी सभी patterns हैं। streaming, batching, caching, retries और यहाँ तक कि benchmarking—अब आप इन्हें लागू करने के लिए तैयार हैं। 

शुरू करने के लिए टेक्स्ट टू स्पीच API के बारे में अधिक जानें या साइन अप करें और आज ElevenAPI के साथ अपनी पहली कॉल करें।

टेक्स्ट टू स्पीच API इंटीग्रेशन FAQ