Modelle

Spitzenmodelle

Text to Speech

Speech to Text

Musik

Modellübersicht

Die ElevenLabs API bietet eine Reihe von Audiomodellen, die für unterschiedliche Anwendungsfälle, Qualitätsstufen und Leistungsanforderungen optimiert sind.

Veraltete Modelle

Eleven v3

Eleven v3 ist unser neuestes und fortschrittlichstes Modell für Sprachsynthese. Es ist ein hochmodernes Modell, das natürliche, lebensechte Sprache mit großer emotionaler Bandbreite und Kontextverständnis in mehreren Sprachen erzeugt.

Dieses Modell eignet sich besonders für folgende Szenarien:

• Charakterdialoge: Hervorragend für Audioerlebnisse mit mehreren Figuren, die miteinander interagieren.
• Hörbuchproduktion: Perfekt für lange Erzählungen mit komplexem emotionalem Ausdruck.
• Emotionale Dialoge: Erzeugen Sie natürliche, lebensechte Dialoge mit großer emotionaler Bandbreite und Kontextverständnis.

Mit Eleven v3 kommt eine neue Text to Dialogue API, mit der Sie natürliche, lebensechte Dialoge mit großer emotionaler Bandbreite und Kontextverständnis in mehreren Sprachen erzeugen können. Eleven v3 kann auch mit der Text to Speech API verwendet werden, um natürliche, lebensechte Sprache mit großer emotionaler Bandbreite und Kontextverständnis in mehreren Sprachen zu erzeugen.

Lesen Sie hier mehr über die Text to Dialogue API.

Unterstützte Sprachen

Das Modell Eleven v3 unterstützt mehr als 70 Sprachen, darunter:

Afrikaans (afr), Arabisch (ara), Armenisch (hye), Assamesisch (asm), Aserbaidschanisch (aze), Belarussisch (bel), Bengalisch (ben), Bosnisch (bos), Bulgarisch (bul), Katalanisch (cat), Cebuano (ceb), Chichewa (nya), Kroatisch (hrv), Tschechisch (ces), Dänisch (dan), Niederländisch (nld), Englisch (eng), Estnisch (est), Filipino (fil), Finnisch (fin), Französisch (fra), Galicisch (glg), Georgisch (kat), Deutsch (deu), Griechisch (ell), Gujarati (guj), Hausa (hau), Hebräisch (heb), Hindi (hin), Ungarisch (hun), Isländisch (isl), Indonesisch (ind), Irisch (gle), Italienisch (ita), Japanisch (jpn), Javanisch (jav), Kannada (kan), Kasachisch (kaz), Kirgisisch (kir), Koreanisch (kor), Lettisch (lav), Lingala (lin), Litauisch (lit), Luxemburgisch (ltz), Mazedonisch (mkd), Malaiisch (msa), Malayalam (mal), Mandarin-Chinesisch (cmn), Marathi (mar), Nepalesisch (nep), Norwegisch (nor), Paschtunisch (pus), Persisch (fas), Polnisch (pol), Portugiesisch (por), Panjabi (pan), Rumänisch (ron), Russisch (rus), Serbisch (srp), Sindhi (snd), Slowakisch (slk), Slowenisch (slv), Somali (som), Spanisch (spa), Suaheli (swa), Schwedisch (swe), Tamil (tam), Telugu (tel), Thailändisch (tha), Türkisch (tur), Ukrainisch (ukr), Urdu (urd), Vietnamesisch (vie), Walisisch (cym).

Eleven v3 Conversational

Eleven v3 Conversational ist unser ausdrucksstärkstes Modell für Sprachsynthese in Echtzeit. Es ist ein hochmodernes Modell, das natürliche, lebensechte Sprache mit großer emotionaler Bandbreite und Kontextverständnis in mehreren Sprachen erzeugt.

Dieses Modell eignet sich besonders für folgende Szenarien:

• Support-Agenten: Betreiben Sie Sprachagenten, die Kundenanfragen in Echtzeit lösen.
• KI-Assistenten: Erzeugen Sie natürliche, lebensechte Dialoge mit großer emotionaler Bandbreite und Kontextverständnis.
• Interaktive Charaktere: Hervorragend für Audioerlebnisse mit ausdrucksstarken Charakteren.

Mit Eleven v3 Conversational kommt ein neues Text to Dialogue WebSocket, mit dem Sie natürliche, lebensechte Dialoge mit großer emotionaler Bandbreite und Kontextverständnis in mehreren Sprachen erzeugen können.

Lesen Sie hier mehr über das Text to Dialogue WebSocket.

Unterstützte Sprachen

Das Modell Eleven v3 unterstützt mehr als 70 Sprachen, darunter:

Afrikaans (afr), Arabisch (ara), Armenisch (hye), Assamesisch (asm), Aserbaidschanisch (aze), Belarussisch (bel), Bengalisch (ben), Bosnisch (bos), Bulgarisch (bul), Katalanisch (cat), Cebuano (ceb), Chichewa (nya), Kroatisch (hrv), Tschechisch (ces), Dänisch (dan), Niederländisch (nld), Englisch (eng), Estnisch (est), Filipino (fil), Finnisch (fin), Französisch (fra), Galicisch (glg), Georgisch (kat), Deutsch (deu), Griechisch (ell), Gujarati (guj), Hausa (hau), Hebräisch (heb), Hindi (hin), Ungarisch (hun), Isländisch (isl), Indonesisch (ind), Irisch (gle), Italienisch (ita), Japanisch (jpn), Javanisch (jav), Kannada (kan), Kasachisch (kaz), Kirgisisch (kir), Koreanisch (kor), Lettisch (lav), Lingala (lin), Litauisch (lit), Luxemburgisch (ltz), Mazedonisch (mkd), Malaiisch (msa), Malayalam (mal), Mandarin-Chinesisch (cmn), Marathi (mar), Nepalesisch (nep), Norwegisch (nor), Paschtunisch (pus), Persisch (fas), Polnisch (pol), Portugiesisch (por), Panjabi (pan), Rumänisch (ron), Russisch (rus), Serbisch (srp), Sindhi (snd), Slowakisch (slk), Slowenisch (slv), Somali (som), Spanisch (spa), Suaheli (swa), Schwedisch (swe), Tamil (tam), Telugu (tel), Thailändisch (tha), Türkisch (tur), Ukrainisch (ukr), Urdu (urd), Vietnamesisch (vie), Walisisch (cym).

Multilingual v2

Eleven Multilingual v2 ist unser fortschrittlichstes, emotional sensibles Modell für Sprachsynthese. Es erzeugt natürliche, lebensechte Sprache mit großer emotionaler Bandbreite und Kontextverständnis in mehreren Sprachen.

Das Modell liefert in allen unterstützten Sprachen eine konsistente Stimmqualität und Persönlichkeit, während die einzigartigen Merkmale und der Akzent des Sprechers erhalten bleiben.

Dieses Modell überzeugt in Szenarien, die hochwertige, emotional nuancierte Sprache erfordern:

• Charakter-Voiceovers: Ideal für Spiele und Animationen dank seiner emotionalen Bandbreite.
• Professionelle Inhalte: Gut geeignet für Unternehmensvideos und E-Learning-Materialien.
• Mehrsprachige Projekte: Behält bei Sprachwechseln eine konsistente Stimmqualität bei.
• Stabile Qualität: Erzeugt konsistent hochwertige Audioausgaben.

Es hat zwar eine höhere Latenz und höhere Kosten pro Zeichen als Flash-Modelle, liefert aber überlegene Qualität für Projekte, bei denen lebensechte Sprache wichtig ist.

Unsere mehrsprachigen v2-Modelle unterstützen 29 Sprachen:

Englisch (USA, UK, Australien, Kanada), Japanisch, Chinesisch, Deutsch, Hindi, Französisch (Frankreich, Kanada), Koreanisch, Portugiesisch (Brasilien, Portugal), Italienisch, Spanisch (Spanien, Mexiko), Indonesisch, Niederländisch, Türkisch, Filipino, Polnisch, Schwedisch, Bulgarisch, Rumänisch, Arabisch (Saudi-Arabien, VAE), Tschechisch, Griechisch, Finnisch, Kroatisch, Malaiisch, Slowakisch, Dänisch, Tamil, Ukrainisch & Russisch.

Flash v2.5

Eleven Flash v2.5 ist unser schnellstes Modell für Sprachsynthese und für Echtzeitanwendungen sowie die Agents Platform konzipiert. Es liefert hochwertige Sprache mit extrem niedriger Latenz (~75ms†) in 32 Sprachen.

Das Modell vereint Geschwindigkeit und Qualität. Damit ist es ideal für interaktive Anwendungen und bewahrt gleichzeitig natürlich klingende Ausgaben sowie konsistente Stimmeigenschaften über alle Sprachen hinweg.

Dieses Modell eignet sich besonders für:

• Agents Platform: Perfekt für Sprachagenten und Chatbots in Echtzeit.
• Interaktive Anwendungen: Ideal für Spiele und Anwendungen, die sofortige Reaktionen erfordern.
• Verarbeitung im großen Maßstab: Effizient für die massenhafte Text-to-Speech-Konvertierung.

Mit seinem niedrigeren Preis für API-Generierungen und einer Latenz von 75 ms ist Flash v2.5 die kosteneffiziente Option für alle, die schnelle und zuverlässige Sprachsynthese in mehreren Sprachen benötigen.

Flash v2.5 unterstützt 32 Sprachen – alle Sprachen der v2-Modelle sowie:

Ungarisch, Norwegisch & Vietnamesisch

Hinweise

Leitfaden zur Modellauswahl

Hinweise dazu, welches Modell am besten zu Ihren Anforderungen und Ihrem Anwendungsfall passt, finden Sie im Leitfaden zur Modellauswahl.

Zeichenlimits

Die maximale Anzahl unterstützter Zeichen in einer einzelnen Text-to-Speech-Anfrage variiert je nach Modell.

Scribe v2

Scribe v2 ist unser hochmodernes Spracherkennungsmodell für präzise Transkription in über 90 Sprachen. Es bietet präzise Zeitstempel auf Wortebene und erweiterte Funktionen wie Sprecherdiarisierung und dynamische Audio-Tags.

Dieses Modell eignet sich besonders für Szenarien, die eine präzise Speech-to-Text-Umwandlung erfordern:

• Transkriptionsdienste: Ideal, um Audio- und Videoinhalte in Text umzuwandeln
• Besprechungsdokumentation: Ideal zum Erfassen und Dokumentieren von Gesprächen
• Inhaltsanalyse: Gut geeignet für die Verarbeitung und Analyse von Audioinhalten
• Mehrsprachige Erkennung: Unterstützt präzise Transkription in über 90 Sprachen

Wichtige Funktionen:

• Präzise Transkription mit Zeitstempeln auf Wortebene
• Sprecherdiarisierung für Audio mit mehreren Sprechern
• Dynamische Audio-Tags für mehr Kontext
• Unterstützung für über 90 Sprachen
• Entitätserkennung
• Keyterm-Prompting
• Bearbeitung von Transkripten

Lesen Sie hier mehr über Scribe v2.

Scribe v2 Realtime

Scribe v2 Realtime, unser schnellstes und präzisestes Modell für Live-Spracherkennung, bietet hochmoderne Genauigkeit in über 90 Sprachen bei einer extrem niedrigen Latenz von 150 ms.

Dieses Modell eignet sich besonders für dialogbasierte Anwendungsfälle:

• Live-Transkription von Besprechungen: Ideal für Echtzeit-Transkription
• KI-Agenten: Ideal für Live-Gespräche
• Mehrsprachige Erkennung: Unterstützt präzise Transkription in über 90 Sprachen mit automatischer Spracherkennung

Wichtige Funktionen:

• Extrem niedrige Latenz: Erhalten Sie Teiltranskriptionen in ~150 Millisekunden
• Streaming-Unterstützung: Senden Sie Audio in Abschnitten und erhalten Sie Transkripte in Echtzeit
• Mehrere Audioformate: Unterstützung für PCM (8 kHz bis 48 kHz) und μ-law-Kodierung
• Voice Activity Detection (VAD): Automatische Sprachsegmentierung anhand von Stilleerkennung
• Manuelle Commit-Steuerung: Volle Kontrolle darüber, wann Transkriptsegmente finalisiert werden
• Entitätserkennung
• Bearbeitung von Transkripten

Lesen Sie hier mehr über Scribe v2 Realtime.

Scribe v2 Medical

Scribe v2 Medical ist ein Batch-Spracherkennungsmodell, das auf medizinische und klinische Audioinhalte spezialisiert ist. Es ist ein Finetune von Scribe v2, das die Erkennung von Medikamentennamen, Anatomie, Pathologie und klinischen Diktaten verbessert und zugleich die Genauigkeit von Scribe v2 bei Alltagssprache erreicht. Es verwendet dieselbe Speech-to-Text-API wie Scribe v2 und wird zum gleichen Tarif abgerechnet. Übergeben Sie scribe_v2_medical als model_id.

Dieses Modell eignet sich gut für:

• Klinische Dokumentation: Umgebungsaufnahmen und Notizen, in denen medizinische Begriffe mitten im Gespräch vorkommen
• Diktate: Dichte Abfolgen von Medikamenten, Dosierungen und Befunden
• Aufnahme- und Koordinationsanrufe: Patienten beschreiben ihre eigenen Beschwerden, oft am Telefon
• Compliance-Workflows: Kombinieren Sie es mit der Entitätserkennung für PHI-Kategorien

Wichtige Funktionen:

• Gleiches Anfrageformat wie Scribe v2 (keyterms, entity_detection, no_verbatim, Diarisierung, Zeitstempel)
• Verbesserte Erkennung von Medikamentennamen sowie Begriffen aus Anatomie und Pathologie
• Keine Verschlechterung bei Alltagssprache gegenüber Scribe v2
• Unterstützung für über 90 Sprachen
• Sprecherdiarisierung für Audio mit mehreren Sprechern
• Dynamische Audio-Tags
• Entitätserkennung, einschließlich PHI-Kategorien

Scribe v2 Medical ist ein Batch-Modell. Verwenden Sie für Live-Transkription Scribe v2 Realtime.

Scribe v2 Medical ist HIPAA-konform nutzbar. Enterprise-Kunden erhalten Business Associate Agreements sowie den Zero Retention Mode (ZRM). Bei aktiviertem ZRM werden Audioeingaben und Textausgaben unmittelbar nach Abschluss jeder Anfrage gelöscht. ElevenLabs speichert nichts. Ihre Anwendung erhält die vollständige API-Antwort und speichert Transkripte unter Ihrer eigenen Kontrolle.

Lesen Sie hier mehr über Speech to Text.

Eleven Music

Eleven Music ist unser Musikgenerierungsmodell in Studioqualität. Damit können Sie Musik in jedem Stil mit natürlichsprachlichen Prompts generieren.

Dieses Modell eignet sich hervorragend für folgende Szenarien:

• Game-Soundtracks: Erstellen Sie immersive Soundtracks für Spiele
• Podcast-Hintergründe: Werten Sie Podcasts mit professioneller Musik auf
• Marketing: Fügen Sie Werbe-Reels Hintergrundmusik hinzu

Wichtige Funktionen:

• Vollständige Kontrolle über Genre, Stil und Struktur
• Gesang oder rein instrumental
• Mehrsprachig, einschließlich Englisch, Spanisch, Deutsch, Japanisch und mehr
• Bearbeiten Sie Sound und Lyrics einzelner Abschnitte oder des gesamten Songs

Lesen Sie hier mehr über Eleven Music.

Parallelität und Priorität

Ihr Abonnement bestimmt, wie viele Anfragen gleichzeitig verarbeitet werden können und welche Prioritätsstufe Ihre Anfragen in der Warteschlange haben. Speech to Text hat ein erhöhtes Parallelitätslimit. Sobald das Parallelitätslimit erreicht ist, werden weitere Anfragen zusammen mit Anfragen niedrigerer Priorität in einer Warteschlange verarbeitet. In der Praxis erhöht dies die Latenz in der Regel nur um etwa 50 ms.

Die Response-Header enthalten current-concurrent-requests und maximum-concurrent-requests, mit denen Sie Ihre Parallelität überwachen können.

API-Anfragen pro Minute vs. parallele Anfragen

Es ist wichtig zu verstehen, dass API-Anfragen pro Minute und parallele Anfragen unterschiedliche Kennzahlen sind, die von Ihren Nutzungsmustern abhängen.

API-Anfragen pro Minute können sich von parallelen Anfragen unterscheiden, da dies von der Dauer jeder Anfrage und der Bündelung der Anfragen abhängt.

Beispiel 1: Zeitlich versetzte Anfragen Wenn Sie 180 Anfragen pro Minute hätten, die jeweils 1 Sekunde dauern, und Sie diese im Abstand von jeweils 0,33 Sekunden senden würden, läge die maximale Anzahl paralleler Anfragen bei 3 und der Durchschnitt ebenfalls bei 3, da immer 3 Anfragen gleichzeitig verarbeitet würden.

Beispiel 2: Gebündelte Anfragen Bei einem anderen Nutzungsmuster mit 180 Anfragen pro Minute, die jeweils 3 Sekunden dauern, aber alle gleichzeitig ausgelöst werden, läge die maximale Anzahl paralleler Anfragen bei 180 und der Durchschnitt bei 9 (in den ersten 3 Sekunden der Minute gab es 180 Anfragen gleichzeitig, in den letzten 57 Sekunden 0 Anfragen).

Da unser System auf Parallelität achtet, sind Anfragen pro Minute weniger wichtig als die Dauer der einzelnen Anfragen und das Muster, nach dem sie gesendet werden.

Wie Endpoint-Anfragen gestellt werden, wirkt sich auf Parallelitätslimits aus:

• Bei HTTP zählt jede Anfrage einzeln für Ihr Parallelitätslimit.
• Beim Text to Speech WebSocket zählt nur die Zeit, in der unser Modell Audio generiert, für Ihr Parallelitätslimit. Das bedeutet, dass ein offener WebSocket die meiste Zeit überhaupt nicht für Ihr Parallelitätslimit zählt.
• Die Text to Dialogue WebSockets funktionieren anders: Jede offene Verbindung reserviert eine Dialogsitzung aus einem separaten Pool, solange sie geöffnet bleibt, und über die Verbindung generiertes Audio zählt nicht für Ihr Standard-Parallelitätslimit. Dies ist einfacher nachzuvollziehen, da eine Verbindung einer Sitzung entspricht. Ihre Dialogsitzungslimits sind an diese neue Methode zur Berechnung der Parallelität angepasst. Siehe Text-to-Dialogue-Parallelität.

Parallelitätslimits verstehen

Das mit Ihrem Tarif verbundene Parallelitätslimit sollte nicht als maximale Anzahl gleichzeitiger Gespräche, Telefonate, Charakter-Voiceovers usw. interpretiert werden, die gleichzeitig verarbeitet werden können. Die tatsächliche Anzahl hängt von mehreren Faktoren ab, einschließlich der verwendeten KI-Stimmen und den Merkmalen des Anwendungsfalls.

Als Faustregel kann ein Parallelitätslimit von 5 in der Regel bis zu etwa 100 gleichzeitige Audioübertragungen unterstützen.

Das liegt an der Geschwindigkeit, mit der Audio generiert wird, im Verhältnis zur Zeit, die für die Verarbeitung der TTS-Anfrage benötigt wird. Das folgende Diagramm zeigt beispielhaft, wie 4 gleichzeitige Anrufe mit unterschiedlichen Nutzern ermöglicht werden können, während nur 2 parallele Anfragen erreicht werden.

Wenn Sie die Parallelitätslimits Ihres Tarifs überschreiten und den Enterprise-Tarif nutzen, können Modellanfragen abhängig von der verfügbaren Kapazität dennoch nach bestem Bemühen erfolgreich sein, allerdings langsamer.

Text-to-Dialogue-Parallelität

Text-to-Dialogue-Anfragen werden je nach Aufruf der API auf zwei verschiedene Arten berechnet:

• HTTP-Endpoints (Dialog erstellen und Dialog streamen) zählen während der Audiogenerierung für das Standard-Parallelitätslimit Ihres Tarifs, wie jede andere Text to Speech-Anfrage.
• WebSocket-Endpoints wie der Text to Dialogue WebSocket werden als Dialogsitzungen berechnet. Eine offene Verbindung belegt eine Dialogsitzung, solange sie geöffnet bleibt, unabhängig davon, ob gerade Audio generiert wird.

Sitzungsbasierte Berechnung vereinfacht die Kapazitätsplanung: Eine Verbindung entspricht einer Sitzung, daher schwankt Ihre Nutzung nicht mit der Generierungsaktivität. Da eine Sitzung für die gesamte Verbindungsdauer belegt wird und nicht nur während der Audiogenerierung, sind Ihre Dialogsitzungslimits an diese neue Methode zur Berechnung der Parallelität angepasst.

Wenn Sie eine Verbindung öffnen, während alle Dialogsitzungen Ihres Workspace belegt sind, wird die neue Verbindung mit einem too_many_concurrent_requests-Fehler abgelehnt. Um Sitzungen freizugeben, schließen Sie nicht mehr benötigte Verbindungen — eine Verbindung wird außerdem nach 20 Sekunden Inaktivität automatisch geschlossen, sofern Sie keine keep_alive-Nachrichten senden.

Um Dialogsitzungen zu überwachen, öffnen Sie unten in der Dashboard-Seitenleiste Developers, wählen Sie den Tab Analytics und sehen Sie sich in der Nutzungsansicht die Kennzahl Concurrent requests an. Dialogsitzungen werden als eigene Reihe, TTD Websocket Sessions, getrennt von Ihren anderen parallelen Anfragen angezeigt.

Parallelitätslimits mit Scale-Tests prüfen

Scale-Tests können helfen, clientseitige Skalierungsprobleme zu erkennen und zu prüfen, ob die Parallelitätslimits für Ihren Anwendungsfall korrekt festgelegt sind.

Es wird dringend empfohlen, End-to-End-Workflows so nah wie möglich an der realen Nutzung zu testen. Die empfohlene Methode hierfür ist, zu simulieren und zu messen, wie viele Nutzer unterstützt werden können. Wichtig ist:

• Simulieren Sie Nutzer, nicht einzelne Anfragen.
• Simulieren Sie typisches Nutzerverhalten, etwa das Warten auf Audiowiedergabe, das Sprechen des Nutzers oder den Abschluss der Transkription, bevor Anfragen gestellt werden.
• Erhöhen Sie die Nutzerzahl über einen Zeitraum von Minuten langsam.
• Fügen Sie den Anfragezeitpunkten und der Größe der Anfragen Zufälligkeit hinzu.
• Erfassen Sie Latenzkennzahlen und alle von der API zurückgegebenen Fehlercodes.

Um beispielsweise ein Agentensystem zu testen, das 100 gleichzeitige Gespräche unterstützen soll, würden Sie bis zu 100 einzelne „Nutzer“ erstellen, die jeweils ein Gespräch simulieren. Gespräche bestehen typischerweise aus einem wiederkehrenden Zyklus von etwa 10 Sekunden, in denen der Nutzer spricht, gefolgt von einem TTS-API-Aufruf für etwa 150 Zeichen und anschließend etwa 10 Sekunden Audiowiedergabe für den Nutzer. Daher sollte jeder Nutzer alle 20 Sekunden einen WebSocket-Text-to-Speech-API-Aufruf für 150 Textzeichen ausführen, wobei der Wartezeit und der Anzahl angeforderter Zeichen eine geringe Zufälligkeit hinzugefügt wird. Der Test würde darin bestehen, pro Sekunde einen Nutzer zu starten, bis 100 existieren, und anschließend insgesamt 10 Minuten zu testen, um die allgemeine Stabilität zu prüfen.

import json
import random
import time
import gevent
import locust
from locust import User, task, events, constant_throughput
import websocket
# Averages up to 10 seconds of audio when played, depends on the voice speed
DEFAULT_TEXT = (
    "Hello, this is a test message. I am testing if a long input will cause issues for the model "
    "like this sentence. "
)
TEXT_ARRAY = [
    "Hello.",
    "Hello, this is a test message.",
    DEFAULT_TEXT,
    DEFAULT_TEXT * 2,
    DEFAULT_TEXT * 3
]
# Custom command line arguments
@events.init_command_line_parser.add_listener
def on_parser_init(parser):
    parser.add_argument("--api-key", default="YOUR_API_KEY", help="API key for authentication")
    parser.add_argument("--encoding", default="mp3_22050_32", help="Encoding")
    parser.add_argument("--text", default=DEFAULT_TEXT, help="Text to use")
    parser.add_argument("--use-text-array", default="false", help="Text to use")
    parser.add_argument("--voice-id", default="aria", help="Text to use")
class WebSocketTTSUser(User):
    # Each user will send a request every 20 seconds, regardless of how long each request takes
    wait_time = constant_throughput(0.05)
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.api_key = self.environment.parsed_options.api_key
        self.voice_id = self.environment.parsed_options.voice_id
        self.text = self.environment.parsed_options.text
        self.encoding = self.environment.parsed_options.encoding
        self.use_text_array = self.environment.parsed_options.use_text_array
        if self.use_text_array:
            self.text = random.choice(TEXT_ARRAY)
        self.all_recieved = False
    @task
    def tts_task(self):
        # Do jitter waiting of up to 1 second
        # Users appear to be spawned every second so this ensures requests are not aligned
        gevent.sleep(random.random())
        max_wait_time = 10
        # Connection details
        uri = f"{self.environment.host}/v1/text-to-speech/{self.voice_id}/stream-input?auto_mode=true&output_format={self.encoding}"
        headers = {"xi-api-key": self.api_key}
        ws = None
        self.all_recieved = False
        try:
            init_msg = {"text": " "}
            # Use proper header format for websocket - this is case sensitive!
            ws = websocket.create_connection(uri, header=headers)
            ws.send(json.dumps(init_msg))
            # Start measuring after websocket initiated but before any messages are sent
            send_request_time = time.perf_counter()
            ws.send(json.dumps({"text": self.text}))
            # Send to flush and receive the audio
            ws.send(json.dumps({"text": ""}))
            def _receive():
                t_first_response = None
                audio_size = 0
                try:
                    while True:
                        # Wait up to 10 seconds for a response
                        ws.settimeout(max_wait_time)
                        response = ws.recv()
                        response_data = json.loads(response)
                        if "audio" in response_data and response_data["audio"]:
                            audio_size = audio_size + len(response_data["audio"])
                        if t_first_response is None:
                            t_first_response = time.perf_counter()
                            first_byte_ms = (
                                t_first_response - send_request_time
                            ) * 1000
                            if audio_size is None:
                                # The first response should always have audio
                                locust.events.request.fire(
                                    request_type="websocket",
                                    name="Bad Response (no audio)",
                                    response_time=first_byte_ms,
                                    response_length=audio_size,
                                    exception=Exception("Response has no audio"),
                                )
                                break
                        if "isFinal" in response_data and response_data["isFinal"]:
                            # Fire this event once finished streaming, but report the important TTFB metric
                            locust.events.request.fire(
                                request_type="websocket",
                                name="TTS Stream Success (First Byte)",
                                response_time=first_byte_ms,
                                response_length=audio_size,
                                exception=None,
                            )
                            break
                except websocket.WebSocketTimeoutException:
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Timeout",
                        response_time=max_wait_time * 1000,
                        response_length=audio_size,
                        exception=Exception("Timeout waiting for response"),
                    )
                except Exception as e:
                    # Typically JSON decode error if the server returns HTTP backoff error
                    locust.events.request.fire(
                        request_type="websocket",
                        name="TTS Stream Failure",
                        response_time=0,
                        response_length=0,
                        exception=e,
                    )
                finally:
                    self.all_recieved = True
            gevent.spawn(_receive)
            # Sleep until recieved so new tasks aren't spawned
            while not self.all_recieved:
                gevent.sleep(1)
        except websocket.WebSocketTimeoutException:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Timeout",
                response_time=max_wait_time * 1000,
                response_length=0,
                exception=Exception("Timeout waiting for response"),
            )
        except Exception as e:
            locust.events.request.fire(
                request_type="websocket",
                name="TTS Stream Failure",
                response_time=0,
                response_length=0,
                exception=e,
            )
        finally:
            # Try and close the websocket gracefully
            try:
                if ws:
                    ws.close()
            except Exception:
                pass