> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt. # Comprendere lo streaming audio Quando guardi un video in streaming, stai scaricando un file. Il server invia byte e il player li memorizza nel buffer finché non ne arrivano abbastanza per la riproduzione. Lo streaming della generazione audio è sostanzialmente diverso. Quando inizia lo streaming, l'audio non esiste ancora. Il modello lo sintetizza in tempo reale e i byte trasmessi sono l'output in tempo reale di questo processo di sintesi. Questa distinzione è importante perché cambia il modo in cui ragioni su latenza, buffering e modalità di errore. ## Cosa succede quando chiami l'endpoint di streaming Quando chiami l'endpoint TTS in streaming di ElevenLabs, si verifica la seguente sequenza: 1. La tua richiesta arriva al server. 2. Il modello inizia a sintetizzare il parlato. 3. Man mano che viene generato l'audio, il server lo invia progressivamente, in genere in chunk di alcuni kilobyte. 4. Il client riceve e riproduce ogni chunk non appena arriva. Il punto fondamentale è il passaggio 3: il server non aspetta che l'intero file audio sia pronto prima di inviarlo. È questo che rende lo streaming sostanzialmente diverso dall'endpoint standard, che attende il completamento della sintesi prima di restituire qualsiasi audio. ## Perché lo streaming riduce il tempo al primo audio Con l'endpoint standard, il tempo al primo audio equivale al tempo necessario per sintetizzare l'intero testo. Per una frase breve potrebbe essere di 500 ms; per un paragrafo potrebbe essere di diversi secondi. Con lo streaming, il tempo al primo audio corrisponde approssimativamente al tempo necessario per sintetizzare il primo chunk audio, in genere le prime centinaia di millisecondi di parlato. Tutto ciò che segue viene riprodotto mentre i chunk successivi vengono generati in parallelo. Ecco perché lo streaming è essenziale per le applicazioni in tempo reale: l'utente sente l'audio entro una frazione di secondo, anche se la generazione completa richiede più tempo. ## I due protocolli di streaming ElevenLabs supporta due approcci di streaming, pensati per casi d'uso diversi. Lo **streaming HTTP** (eventi inviati dal server) è l'approccio più semplice. Invi un testo completo in anticipo e il server trasmette l'audio man mano che viene generato. Funziona bene quando hai tutto il testo prima di iniziare, ad esempio uno script scritto in precedenza o una risposta completa di un LLM che vuoi riprodurre subito. Lo **streaming WebSocket** abilita la comunicazione bidirezionale. Puoi inviare il testo in modo incrementale, parola per parola o frase per frase, e il modello inizia a generare prima che l'input completo sia disponibile. Questo rende possibili pipeline vocali end-to-end a bassa latenza: un LLM genera token, tu li inoltri al WebSocket TTS man mano che arrivano e l'audio inizia a essere riprodotto prima ancora che l'LLM abbia terminato la risposta. L'approccio WebSocket introduce maggiore complessità. Il modello deve decidere quando iniziare a generare l'audio: se lo fa troppo presto, potrebbe produrre una prosodia innaturale ai confini delle frasi; se lo fa troppo tardi, la latenza ne risente. Questo comportamento è controllato tramite le pianificazioni dei chunk e l'impostazione `auto_mode`, che gestisce automaticamente questo compromesso nella maggior parte dei casi d'uso. ## Perché la dimensione dei chunk influisce sia sulla latenza sia sulla naturalezza Nella generazione audio in streaming esiste una tensione fondamentale tra la dimensione dei chunk e la naturalezza del parlato. I modelli di sintesi vocale traggono vantaggio dal contesto. Sapere cosa precede e segue una determinata parola aiuta il modello a produrre una prosodia naturale. Un modello che genera audio da "The economy" deve considerare una prosodia molto diversa a seconda che la frase termini con "is recovering" oppure "is in freefall." Generare l'audio troppo presto, prima che il modello abbia ricevuto abbastanza testo, rischia di produrre un parlato che suona innaturale ai confini delle frasi: tecnicamente corretto, ma leggermente robotico. Attendere più contesto migliora la naturalezza, ma aumenta la latenza. La modalità `auto_mode` di ElevenLabs cerca di trovare automaticamente un buon equilibrio analizzando il testo in arrivo. Per la maggior parte delle applicazioni, produce buoni risultati. Quando hai bisogno di un controllo più preciso, ad esempio in un agente vocale in cui sei disposto ad accettare una prosodia leggermente meno naturale in cambio di una latenza inferiore, puoi configurare direttamente la pianificazione dei chunk. ## Latenza di streaming e latenza di generazione È facile confondere questi due valori, ma sono diversi. La **latenza di generazione** è il tempo impiegato dal modello per produrre l'audio. È a questo che si riferisce il dato di circa 75 ms del modello Flash: il tempo di inferenza del modello per un breve input di testo, esclusi i round-trip di rete e l'overhead dell'applicazione. Il **tempo al primo audio** è il tempo che intercorre dall'avvio di una richiesta da parte dell'applicazione al momento in cui il primo campione audio viene effettivamente riprodotto per l'utente finale. Include la latenza di rete, il tempo di elaborazione del server e qualsiasi buffering introdotto dal player audio. In pratica, puoi aspettarti che il tempo al primo audio sia notevolmente superiore alla sola latenza del modello. I round-trip di rete aggiungono 50–200 ms a seconda della distanza geografica. Anche il buffer del player audio aggiunge ulteriore latenza. Comprendere questa distinzione ti aiuta a definire aspettative realistiche e a diagnosticare problemi di prestazioni: se il tempo al primo audio è elevato, il collo di bottiglia è in genere la rete o il buffering dell'applicazione, non le prestazioni del modello. ## Idee sbagliate comuni **"L'endpoint di streaming è più lento perché invia i dati in modo incrementale."** No, è più veloce per gli utenti perché sentono l'audio prima. Il tempo di generazione totale è simile; ciò che cambia è quando i dati iniziano ad arrivare. **"Mi servono i WebSocket per lo streaming."** Non necessariamente. L'endpoint di streaming HTTP gestisce bene la maggior parte dei casi d'uso. I WebSocket sono particolarmente utili quando generi testo e audio contemporaneamente, ad esempio quando un LLM produce testo che alimenta direttamente la generazione audio. **"I formati audio di qualità superiore aumentano significativamente la latenza di streaming."** Nella maggior parte dei casi è un'esagerazione. I principali fattori di latenza sono il tempo di inferenza del modello e il round-trip di rete. Un formato di output con bitrate più elevato aggiunge un overhead modesto, che raramente vale la pena ottimizzare prima di affrontare i fattori più rilevanti. ## Correlati #### [Guida pratica allo streaming](/docs/it/eleven-api/guides/how-to/text-to-speech/streaming) Implementazione pratica con codice per lo streaming HTTP e WebSocket. #### [Guida ai WebSocket](/docs/it/eleven-api/guides/how-to/websockets/realtime-tts) Usa l'endpoint WebSocket bidirezionale per la generazione audio in tempo reale. #### [Comprendere la latenza](/docs/it/eleven-api/concepts/latency) Uno sguardo più ampio ai fattori che contribuiscono alla latenza end-to-end nella generazione audio. #### [Ottimizzazione della latenza](/docs/it/eleven-api/guides/how-to/best-practices/latency-optimization) Tecniche specifiche e opzioni di configurazione per ridurre il tempo al primo audio.