Generera ljud i realtid
Den här guiden visar hur du genererar ljud i realtid via en WebSocket-anslutning.
WebSocket-streaming är en metod för att skicka och ta emot data över en enda, långvarig anslutning. Metoden är användbar för realtidsapplikationer där du behöver streama ljuddata så snart den blir tillgänglig.
Om du snabbt vill testa latensen (tid till första byte) för en WebSocket-anslutning till ElevenLabs Text to Speech API kan du installera elevenlabs-latency via npm och följa instruktionerna här.
WebSockets är tillgängliga för Text to Speech och Agents Platform. Den här guiden handlar om Text
to Speech-WebSocketen (/v1/text-to-speech/{voice_id}/stream-input). Den slutpunkten stöder inte
modellerna eleven_v3 eller eleven_v4. För dialog med Eleven v3 eller Eleven v4 över en
WebSocket, se Text till dialog i realtid
och Text to Speech- kontra Text to Dialogue-
WebSockets.
Krav
- Ett ElevenLabs-konto med en API-nyckel (så här hittar du din API-nyckel).
- Python eller Node.js (eller en annan JavaScript-runtime) installerat på din dator
Konfiguration
Installera nödvändiga beroenden:
Skapa sedan en .env-fil i projektkatalogen och lägg till din API-nyckel:
Upprätta WebSocket-anslutningen
När du har valt en röst från Voice Library och den text till tal-modell du vill använda, upprättar du en WebSocket-anslutning till text till tal-API:et.
Skicka indatatexten
När WebSocket-anslutningen är öppen ska du först ange röstinställningar. Skicka sedan textmeddelandet till API:et.
Spara ljudet till en fil
Läs det inkommande meddelandet från WebSocket-anslutningen och skriv ljudsegmenten till en lokal fil.
Kör skriptet
Du kan köra skriptet genom att köra följande kommando i terminalen. En mp3-ljudfil sparas i katalogen output.
Avancerad konfiguration
WebSockets har några avancerade inställningar som du kan använda för att finjustera ljudgenerering i realtid.
Buffring
Vid ljudgenerering i realtid bör du ta hänsyn till två viktiga begrepp: Time To First Byte (TTFB) och buffring. För att skapa ljud av hög kvalitet och förstå sammanhang behöver modellen en viss mängd indatatext. Ju mer text som skickas i en WebSocket-anslutning, desto bättre blir ljudkvaliteten. Om tröskelvärdet inte uppnås lägger modellen texten i en buffert och genererar ljud när bufferten är full.
När det gäller latens är TTFB tiden det tar innan den första ljudbyten skickas till klienten. Detta är viktigt eftersom det påverkar den upplevda ljudlatensen. Därför kan du vilja styra buffertstorleken för att balansera kvalitet och latens.
För att hantera detta kan du använda parametern chunk_length_schedule när du antingen initierar WebSocket-anslutningen eller skickar text. Parametern är en matris med heltal som representerar antalet tecken som skickas till modellen innan ljud genereras. Om du till exempel anger chunk_length_schedule till [120, 160, 250, 290] genererar modellen ljud efter att 120, 160, 250 respektive 290 tecken har skickats.
Så här fungerar det med standardinställningarna för chunk_length_schedule:
I diagrammet ovan genereras ljud först efter att det andra meddelandet har skickats till servern. Det beror på att det första meddelandet är under tröskelvärdet på 120 tecken, medan det andra meddelandet gör att det totala antalet tecken hamnar över tröskelvärdet. Det tredje meddelandet är över tröskelvärdet på 160 tecken, så ljud genereras direkt och returneras till klienten.
Du kan ange ett anpassat värde för chunk_length_schedule när du initierar WebSocket-anslutningen eller skickar text.
Om du vill tvinga fram omedelbar returnering av ljudet kan du använda flush: true för att tömma bufferten och tvinga fram generering av buffrad text. Det kan till exempel vara användbart när du har nått slutet av ett dokument och vill generera ljud för den sista delen.
Du kan ange detta för varje enskilt meddelande genom att ställa in flush: true i meddelandet.
Dessutom kommer WebSocketen automatiskt att tvinga fram generering av buffrad text när den stängs.
Röstinställningar
När du initierar WebSocket-anslutningar kan du ange röstinställningar för efterföljande genereringar. På så sätt kan du styra hastighet, stabilitet och andra röstegenskaper för det genererade ljudet.
Detta kan åsidosättas för varje enskilt meddelande genom att ange andra voice_settings i meddelandet.
Uttalslexikon
Du kan använda uttalslexikon för att styra uttalet av specifika ord eller fraser. Det kan vara användbart för att säkerställa att vissa ord uttalas korrekt eller för att betona vissa ord eller fraser.
Till skillnad från voice_settings och generation_config måste uttalslexikon anges i meddelandet “Initialize Connection”. Mer information finns i API-referensen.
När du använder fonემბaserade uttalslexikon med WebSockets måste du lägga till enable_ssml_parsing=true som en frågeparameter i WebSocket-URI:n. Till exempel:
Bästa praxis
- Vi rekommenderar att du använder standardinställningen för
chunk_length_scheduleigeneration_config. - När du utvecklar en applikation för en konversationsagent i realtid rekommenderar vi att du använder
flush: truetillsammans med texten i slutet av en samtalstur för att säkerställa ljudgenerering i rätt tid. - Om standardinställningen inte ger optimal latens för ditt användningsfall kan du ändra
chunk_length_schedule. Tänk dock på att lägre latens genom denna justering kan ske på bekostnad av kvaliteten.
Tips
- WebSocket-anslutningen stängs automatiskt efter 20 sekunders inaktivitet. För att hålla anslutningen öppen kan du skicka ett enskilt blankstegstecken
" ". Observera att strängen måste innehålla ett blanksteg, eftersom en helt tom sträng,"", stänger WebSocketen. - Skicka en tom sträng för att stänga WebSocket-anslutningen efter att du har skickat det sista textmeddelandet.
- Du kan använda
alignmentför att få tidsstämplar på ordnivå för varje ord i texten. Det kan vara användbart för att synkronisera ljudet med texten i en video eller för andra applikationer som kräver exakt tidsangivelse. Mer information finns i API-referensen.