Modelos

Modelos insignia

Texto a Voz

Voz a Texto

Música

Resumen de modelos

La API de ElevenLabs ofrece una gama de modelos de audio optimizados para distintos casos de uso, niveles de calidad y requisitos de rendimiento.

Modelos obsoletos

Eleven v4

Eleven v4 es nuestro modelo de síntesis de voz más avanzado, que ofrece audio de la máxima calidad, expresividad y control sobre la interpretación de las voces. Eleven v4 admite la clonación de voz de alta fidelidad y conserva de forma fiable las características del hablante en generaciones de texto largas.

Este modelo funciona bien en los siguientes casos:

• Locuciones de personajes: Ideal para videojuegos y animación por su rango emocional.
• Diálogo emocional: Genera diálogos naturales y realistas, con un amplio rango emocional y comprensión contextual.
• Producción de audiolibros: Perfecto para narraciones largas con una interpretación emocional compleja.
• Proyectos multilingües: Mantiene una calidad de voz uniforme al cambiar de idioma.

Eleven v4 está disponible a través de la API de Texto a Diálogo.

Idiomas compatibles

La familia de modelos Eleven v4 es compatible con más de 90 idiomas, incluidos:

Afrikáans (afr), amárico (amh), árabe (ara), armenio (hye), asamés (asm), asturiano (ast), azerbaiyano (aze), bielorruso (bel), bengalí (ben), bosnio (bos), búlgaro (bul), birmano (mya), cantonés (yue), catalán (cat), cebuano (ceb), croata (hrv), checo (ces), danés (dan), neerlandés (nld), inglés (eng), estonio (est), filipino (fil), finés (fin), francés (fra), fula/pulaar (ful), gallego (glg), georgiano (kat), alemán (deu), griego (ell), guyaratí (guj), hausa (hau), hebreo (heb), hindi (hin), húngaro (hun), islandés (isl), indonesio (ind), italiano (ita), japonés (jpn), javanés (jav), kamba (kam), canarés (kan), kazajo (kaz), coreano (kor), kirguís (kir), lao (lao), letón (lav), lingala (lin), lituano (lit), luganda (lug), luxemburgués (ltz), macedonio (mkd), malayo (msa), malayalam (mal), maltés (mlt), chino mandarín (cmn), maorí (mri), maratí (mar), mongol (mon), nepalí (nep), bokmål noruego (nob), occitano (oci), odia (ori), pastún (pus), persa (fas), polaco (pol), portugués de Brasil (por), panyabí (pan), rumano (ron), ruso (rus), serbio (srp), shona (sna), sindhi (snd), eslovaco (slk), esloveno (slv), somalí (som), kurdo soraní (ckb), español de Latinoamérica (spa), suajili (swa), sueco (swe), tayiko (tgk), tamil (tam), telugu (tel), tailandés (tha), turco (tur), ucraniano (ukr), urdu (urd), uzbeko (uzb), vietnamita (vie), galés (cym), wólof (wol), zulú (zul).

Eleven v4 Turbo

Eleven v4 Turbo es nuestro modelo más avanzado para la síntesis de voz en tiempo real, que ofrece audio de alta calidad, expresividad y control sobre la interpretación de las voces. Eleven v4 Turbo admite la clonación de voz de alta fidelidad y ofrece resultados con una latencia de inferencia media de ~100 ms.

Este modelo funciona bien en los siguientes casos:

• Agentes de soporte: Impulsa agentes de voz que resuelven consultas de clientes en tiempo real.
• Asistentes de IA: Genera diálogos naturales y realistas, con un amplio rango emocional y comprensión contextual.
• Personajes interactivos: Excelente para experiencias de audio con personajes expresivos.

Eleven v4 Turbo está disponible a través del WebSocket de Texto a Diálogo.

Idiomas compatibles

La familia de modelos Eleven v4 es compatible con más de 90 idiomas, incluidos:

Afrikáans (afr), amárico (amh), árabe (ara), armenio (hye), asamés (asm), asturiano (ast), azerbaiyano (aze), bielorruso (bel), bengalí (ben), bosnio (bos), búlgaro (bul), birmano (mya), cantonés (yue), catalán (cat), cebuano (ceb), croata (hrv), checo (ces), danés (dan), neerlandés (nld), inglés (eng), estonio (est), filipino (fil), finés (fin), francés (fra), fula/pulaar (ful), gallego (glg), georgiano (kat), alemán (deu), griego (ell), guyaratí (guj), hausa (hau), hebreo (heb), hindi (hin), húngaro (hun), islandés (isl), indonesio (ind), italiano (ita), japonés (jpn), javanés (jav), kamba (kam), canarés (kan), kazajo (kaz), coreano (kor), kirguís (kir), lao (lao), letón (lav), lingala (lin), lituano (lit), luganda (lug), luxemburgués (ltz), macedonio (mkd), malayo (msa), malayalam (mal), maltés (mlt), chino mandarín (cmn), maorí (mri), maratí (mar), mongol (mon), nepalí (nep), bokmål noruego (nob), occitano (oci), odia (ori), pastún (pus), persa (fas), polaco (pol), portugués de Brasil (por), panyabí (pan), rumano (ron), ruso (rus), serbio (srp), shona (sna), sindhi (snd), eslovaco (slk), esloveno (slv), somalí (som), kurdo soraní (ckb), español de Latinoamérica (spa), suajili (swa), sueco (swe), tayiko (tgk), tamil (tam), telugu (tel), tailandés (tha), turco (tur), ucraniano (ukr), urdu (urd), uzbeko (uzb), vietnamita (vie), galés (cym), wólof (wol), zulú (zul).

Eleven v3

Eleven v3 es nuestro modelo de síntesis de voz de la generación anterior, que produce una voz natural y realista con un amplio rango emocional y comprensión contextual en varios idiomas.

Con Eleven v3 llega una nueva API de Texto a Diálogo que te permite generar diálogos naturales y realistas, con un amplio rango emocional y comprensión contextual en varios idiomas. También puedes usar Eleven v3 con la API de Texto a Voz para generar voz natural y realista, con un amplio rango emocional y comprensión contextual en varios idiomas.

Más información sobre la API de Texto a Diálogo aquí.

Idiomas compatibles

El modelo Eleven v3 es compatible con más de 70 idiomas, incluidos:

Afrikáans (afr), árabe (ara), armenio (hye), asamés (asm), azerbaiyano (aze), bielorruso (bel), bengalí (ben), bosnio (bos), búlgaro (bul), catalán (cat), cebuano (ceb), chichewa (nya), croata (hrv), checo (ces), danés (dan), neerlandés (nld), inglés (eng), estonio (est), filipino (fil), finés (fin), francés (fra), gallego (glg), georgiano (kat), alemán (deu), griego (ell), guyaratí (guj), hausa (hau), hebreo (heb), hindi (hin), húngaro (hun), islandés (isl), indonesio (ind), irlandés (gle), italiano (ita), japonés (jpn), javanés (jav), canarés (kan), kazajo (kaz), kirguís (kir), coreano (kor), letón (lav), lingala (lin), lituano (lit), luxemburgués (ltz), macedonio (mkd), malayo (msa), malayalam (mal), chino mandarín (cmn), maratí (mar), nepalí (nep), noruego (nor), pastún (pus), persa (fas), polaco (pol), portugués (por), panyabí (pan), rumano (ron), ruso (rus), serbio (srp), sindhi (snd), eslovaco (slk), esloveno (slv), somalí (som), español (spa), suajili (swa), sueco (swe), tamil (tam), telugu (tel), tailandés (tha), turco (tur), ucraniano (ukr), urdu (urd), vietnamita (vie), galés (cym).

Eleven v3 Conversational

Eleven v3 Conversational es nuestro modelo de generación anterior para la síntesis de voz en tiempo real. Produce una voz natural y realista con un amplio rango emocional y comprensión contextual en varios idiomas.

Con Eleven v3 Conversational llega un nuevo WebSocket de Texto a Diálogo que te permite generar diálogos naturales y realistas, con un amplio rango emocional y comprensión contextual en varios idiomas.

Con Eleven v3 Conversational llega un nuevo WebSocket de Texto a Diálogo que te permite generar diálogos naturales y realistas, con un amplio rango emocional y comprensión contextual en varios idiomas.

Más información sobre el WebSocket de Texto a Diálogo aquí.

Idiomas compatibles

El modelo Eleven v3 es compatible con más de 70 idiomas, incluidos:

Afrikáans (afr), árabe (ara), armenio (hye), asamés (asm), azerbaiyano (aze), bielorruso (bel), bengalí (ben), bosnio (bos), búlgaro (bul), catalán (cat), cebuano (ceb), chichewa (nya), croata (hrv), checo (ces), danés (dan), neerlandés (nld), inglés (eng), estonio (est), filipino (fil), finés (fin), francés (fra), gallego (glg), georgiano (kat), alemán (deu), griego (ell), guyaratí (guj), hausa (hau), hebreo (heb), hindi (hin), húngaro (hun), islandés (isl), indonesio (ind), irlandés (gle), italiano (ita), japonés (jpn), javanés (jav), canarés (kan), kazajo (kaz), kirguís (kir), coreano (kor), letón (lav), lingala (lin), lituano (lit), luxemburgués (ltz), macedonio (mkd), malayo (msa), malayalam (mal), chino mandarín (cmn), maratí (mar), nepalí (nep), noruego (nor), pastún (pus), persa (fas), polaco (pol), portugués (por), panyabí (pan), rumano (ron), ruso (rus), serbio (srp), sindhi (snd), eslovaco (slk), esloveno (slv), somalí (som), español (spa), suajili (swa), sueco (swe), tamil (tam), telugu (tel), tailandés (tha), turco (tur), ucraniano (ukr), urdu (urd), vietnamita (vie), galés (cym).

Multilingual v2

Eleven Multilingual v2 es un modelo de síntesis de voz de la generación anterior con sensibilidad emocional. Produce una voz natural y realista con un amplio rango emocional y comprensión contextual en varios idiomas.

El modelo ofrece una calidad y personalidad de voz uniformes en todos los idiomas compatibles, al tiempo que conserva las características y el acento únicos del hablante.

Este modelo destaca en situaciones que requieren una voz de alta calidad y con matices emocionales:

• Locuciones de personajes: Ideal para videojuegos y animación por su rango emocional.
• Contenido profesional: Muy adecuado para vídeos corporativos y materiales de e-learning.
• Proyectos multilingües: Mantiene una calidad de voz uniforme al cambiar de idioma.
• Calidad estable: Produce una salida de audio uniforme y de alta calidad.

Aunque tiene una latencia y un coste por carácter mayores que los modelos Flash, ofrece una calidad superior para proyectos en los que una voz realista es importante.

Nuestros modelos multilingües v2 son compatibles con 29 idiomas:

Inglés (EE. UU., Reino Unido, Australia, Canadá), japonés, chino, alemán, hindi, francés (Francia, Canadá), coreano, portugués (Brasil, Portugal), italiano, español (España, México), indonesio, neerlandés, turco, filipino, polaco, sueco, búlgaro, rumano, árabe (Arabia Saudí, EAU), checo, griego, finés, croata, malayo, eslovaco, danés, tamil, ucraniano y ruso.

Flash v2.5

Eleven Flash v2.5 es nuestro modelo de síntesis de voz más rápido, diseñado para aplicaciones en tiempo real y Agents Platform. Ofrece voz de alta calidad con una latencia ultrabaja (~75 ms†) en 32 idiomas.

El modelo equilibra velocidad y calidad, por lo que es ideal para aplicaciones interactivas, a la vez que mantiene un resultado con sonido natural y características de voz uniformes entre idiomas.

Este modelo es especialmente adecuado para:

• Agents Platform: Perfecto para agentes de voz y chatbots en tiempo real.
• Aplicaciones interactivas: Ideal para juegos y aplicaciones que requieren una respuesta inmediata.
• Procesamiento a gran escala: Eficiente para la conversión masiva de texto a voz.

Con su precio más bajo para generaciones mediante API y una latencia de 75 ms, Flash v2.5 es la opción rentable para quien necesite una síntesis de voz rápida y fiable en varios idiomas.

Flash v2.5 es compatible con 32 idiomas: todos los idiomas de los modelos v2, además de:

Húngaro, noruego y vietnamita

Consideraciones

Guía de selección de modelos

Para saber qué modelo se ajusta mejor a tus requisitos y caso de uso, consulta la guía de selección de modelos.

Límites de caracteres

El número máximo de caracteres admitidos en una sola solicitud de texto a voz varía según el modelo.

Scribe v2

Scribe v2 es nuestro modelo de reconocimiento de voz más avanzado, diseñado para ofrecer transcripciones precisas en más de 90 idiomas. Proporciona marcas de tiempo precisas a nivel de palabra y funciones avanzadas como la diarización de hablantes y el etiquetado dinámico de audio.

Este modelo destaca en situaciones que requieren una conversión precisa de voz a texto:

• Servicios de transcripción: Perfecto para convertir contenido de audio y vídeo en texto.
• Documentación de reuniones: Ideal para capturar y documentar conversaciones.
• Análisis de contenido: Muy adecuado para el procesamiento y análisis de contenido de audio.
• Reconocimiento multilingüe: Admite transcripción precisa en más de 90 idiomas.

Funciones principales:

• Transcripción precisa con marcas de tiempo a nivel de palabra
• Diarización de hablantes para audio con varios hablantes
• Etiquetado dinámico de audio para mejorar el contexto
• Compatibilidad con más de 90 idiomas
• Detección de entidades
• Prompting de términos clave
• Edición de transcripciones

Más información sobre Scribe v2 aquí.

Scribe v2 Realtime

Scribe v2 Realtime, nuestro modelo de reconocimiento de voz en directo más rápido y preciso, ofrece una precisión de última generación en más de 90 idiomas con una latencia ultrabaja de 150 ms.

Este modelo destaca en casos de uso conversacionales:

• Transcripción de reuniones en directo: Perfecto para transcripción en tiempo real.
• Agentes de IA: Ideal para conversaciones en directo.
• Reconocimiento multilingüe: Admite transcripción precisa en más de 90 idiomas con reconocimiento automático del idioma.

Funciones principales:

• Latencia ultrabaja: obtén transcripciones parciales en ~150 milisegundos
• Compatibilidad con streaming: envía audio por fragmentos mientras recibes transcripciones en tiempo real
• Varios formatos de audio: compatibilidad con PCM (de 8 kHz a 48 kHz) y codificación μ-law
• Detección de actividad de voz (VAD): segmentación automática de voz basada en la detección de silencios
• Control de confirmación manual: control total sobre cuándo finalizar los segmentos de transcripción
• Detección de entidades
• Edición de transcripciones

Más información sobre Scribe v2 Realtime aquí.

Scribe v2 Medical

Scribe v2 Medical es un modelo de reconocimiento de voz por lotes especializado en audio médico y clínico. Es un ajuste fino de Scribe v2 que mejora el reconocimiento de nombres de medicamentos, anatomía, patología y dictado clínico, al tiempo que iguala la precisión de Scribe v2 en el habla cotidiana. Utiliza la misma API de Voz a Texto que Scribe v2 y se factura a la misma tarifa. Pasa scribe_v2_medical como model_id.

Este modelo es adecuado para:

• Documentación clínica: Consultas ambientales y notas en las que aparecen términos médicos a mitad de la conversación.
• Dictado: Secuencias densas de medicamentos, dosis y hallazgos.
• Llamadas de admisión y coordinación: Pacientes que describen sus propias condiciones, a menudo por teléfono.
• Flujos de trabajo de cumplimiento normativo: Combínalo con la detección de entidades para categorías de PHI.

Funciones principales:

• Misma estructura de solicitud que Scribe v2 (keyterms, entity_detection, no_verbatim, diarización, marcas de tiempo)
• Mejor reconocimiento de nombres de medicamentos y términos de anatomía y patología
• Sin pérdida de precisión en el habla cotidiana respecto a Scribe v2
• Compatibilidad con más de 90 idiomas
• Diarización de hablantes para audio con varios hablantes
• Etiquetado dinámico de audio
• Detección de entidades, incluidas categorías de PHI

Scribe v2 Medical es un modelo por lotes. Para transcripción en directo, usa Scribe v2 Realtime.

Scribe v2 Medical es apto para HIPAA, con acuerdos de asociado comercial disponibles para clientes Enterprise, así como el modo de retención cero (ZRM). Con ZRM activado, la entrada de audio y la salida de texto se eliminan inmediatamente después de completarse cada solicitud. ElevenLabs no conserva nada, y tu aplicación recibe la respuesta completa de la API y conserva las transcripciones bajo tus propios controles.

Más información sobre Voz a Texto aquí.

Eleven Music

Eleven Music es nuestro modelo de generación de música con calidad de estudio. Te permite generar música de cualquier estilo mediante prompts en lenguaje natural.

Este modelo es excelente para los siguientes casos:

• Bandas sonoras para juegos: Crea bandas sonoras envolventes para juegos.
• Fondos para podcasts: Mejora los podcasts con música profesional.
• Marketing: Añade música de fondo a vídeos publicitarios.

Funciones principales:

• Control total sobre el género, el estilo y la estructura
• Con voz o solo instrumental
• Multilingüe, incluidos inglés, español, alemán, japonés y más
• Edita el sonido y la letra de secciones individuales o de toda la canción

Más información sobre Eleven Music aquí.

Concurrencia y prioridad

Tu plan de suscripción determina cuántas solicitudes se pueden procesar simultáneamente y el nivel de prioridad de tus solicitudes en la cola. Voz a Texto tiene un límite de concurrencia superior. Una vez alcanzado el límite de concurrencia, las solicitudes posteriores se procesan en una cola junto con solicitudes de menor prioridad. En la práctica, esto normalmente solo añade unos ~50 ms de latencia.

Las cabeceras de respuesta incluyen current-concurrent-requests y maximum-concurrent-requests, que puedes usar para supervisar tu concurrencia.

Solicitudes a la API por minuto frente a solicitudes simultáneas

Es importante entender que las solicitudes a la API por minuto y las solicitudes simultáneas son métricas diferentes que dependen de tus patrones de uso.

Las solicitudes a la API por minuto pueden ser distintas de las solicitudes simultáneas, ya que dependen de la duración de cada solicitud y de cómo se agrupan las solicitudes.

Ejemplo 1: Solicitudes espaciadas Si tuvieras 180 solicitudes por minuto que tardaran 1 segundo cada una en completarse y las enviaras con 0,33 segundos de intervalo, el máximo de solicitudes simultáneas sería 3 y la media también sería 3, ya que siempre habría 3 en curso.

Ejemplo 2: Solicitudes por lotes Sin embargo, si tuvieras un patrón de uso diferente, como 180 solicitudes por minuto que tardaran 3 segundos cada una en completarse, pero se lanzaran todas a la vez, el máximo de solicitudes simultáneas sería 180 y la media sería 9 (los primeros 3 segundos del minuto tendrían 180 solicitudes a la vez y los últimos 57 segundos tendrían 0 solicitudes).

Como nuestro sistema tiene en cuenta la concurrencia, las solicitudes por minuto importan menos que la duración de cada solicitud y el patrón con el que se envían.

La forma de realizar solicitudes a las rutas de API afecta a los límites de concurrencia:

• Con HTTP, cada solicitud cuenta individualmente para tu límite de concurrencia.
• Con el WebSocket de Texto a Voz, solo cuenta para tu límite de concurrencia el tiempo durante el cual nuestro modelo genera audio. Esto significa que, durante la mayor parte del tiempo, un websocket abierto no cuenta en absoluto para tu límite de concurrencia.
• Los WebSockets de Texto a Diálogo funcionan de forma distinta: cada conexión abierta reserva una sesión de diálogo de un grupo independiente mientras permanezca abierta, y el audio generado a través de la conexión no cuenta para tu límite de concurrencia estándar. Esto está diseñado para que sea más fácil de entender: una conexión equivale a una sesión, y los límites de tus sesiones de diálogo están dimensionados para adaptarse a esta nueva metodología de concurrencia. Consulta la concurrencia de Texto a Diálogo.

Comprender los límites de concurrencia

El límite de concurrencia asociado a tu plan no debe interpretarse como el número máximo de conversaciones simultáneas, llamadas telefónicas, locuciones de personajes, etc. que se pueden gestionar a la vez. El número real depende de varios factores, incluidas las voces IA específicas utilizadas y las características del caso de uso.

Como regla general, un límite de concurrencia de 5 suele poder admitir hasta aproximadamente 100 emisiones de audio simultáneas.

Esto se debe a la velocidad con la que se genera el audio en relación con el tiempo que tarda en procesarse la solicitud de TTS. El diagrama de abajo muestra un ejemplo de cómo se pueden gestionar 4 llamadas simultáneas con distintos usuarios utilizando solo 2 solicitudes simultáneas.

Si superas los límites de concurrencia de tu plan en algún momento y tienes el plan Enterprise, las solicitudes al modelo aún pueden realizarse correctamente, aunque más despacio, según la capacidad disponible y haciendo todo lo posible.

Concurrencia de Texto a Diálogo

Las solicitudes de Texto a Diálogo se miden de dos formas distintas según cómo llames a la API:

• Las rutas HTTP (Crear diálogo y Transmitir diálogo) cuentan para el límite de concurrencia estándar de tu plan mientras se genera audio, como cualquier otra solicitud de Texto a Voz.
• Las rutas WebSocket, como el WebSocket de Texto a Diálogo, se miden como sesiones de diálogo. Una conexión abierta mantiene una sesión de diálogo mientras permanece abierta, tanto si se está generando audio como si no.

La medición basada en sesiones simplifica la planificación de capacidad: una conexión equivale a una sesión, por lo que tu uso no fluctúa con la actividad de generación. Como se mantiene una sesión durante toda la conexión en lugar de solo mientras se genera audio, los límites de tus sesiones de diálogo están dimensionados para adaptarse a esta nueva metodología de concurrencia.

Si abres una conexión mientras se están usando todas las sesiones de diálogo de tu espacio de trabajo, la nueva conexión se rechaza con un error too_many_concurrent_requests. Para liberar sesiones, cierra las conexiones que ya no necesites; una conexión también se cierra automáticamente después de 20 segundos de inactividad, a menos que envíes mensajes keep_alive.

Para supervisar las sesiones de diálogo, abre Developers en la parte inferior de la barra lateral del panel, selecciona la pestaña Analytics y consulta la métrica Concurrent requests en la vista de uso. Las sesiones de diálogo se muestran como una serie independiente, TTD Websocket Sessions, separada de tus otras solicitudes simultáneas.

Pruebas de carga de los límites de concurrencia

Las pruebas de carga pueden ser útiles para identificar problemas de escalado en el lado del cliente y verificar que los límites de concurrencia estén configurados correctamente para tu caso de uso.

Se recomienda encarecidamente probar los flujos de trabajo de principio a fin lo más cerca posible del uso real. La metodología recomendada para lograrlo es simular y medir cuántos usuarios se pueden admitir. Es importante:

• Simular usuarios, no solicitudes sin procesar
• Simular el comportamiento habitual de los usuarios, como esperar a que termine la reproducción del audio, que el usuario hable o que finalice la transcripción antes de realizar solicitudes
• Aumentar el número de usuarios gradualmente durante varios minutos
• Introducir aleatoriedad en los tiempos de las solicitudes y en el tamaño de las solicitudes
• Registrar métricas de latencia y cualquier código de error devuelto por la API

Por ejemplo, para probar un sistema de agentes diseñado para admitir 100 conversaciones simultáneas, crearías hasta 100 “usuarios” individuales, cada uno simulando una conversación. Las conversaciones suelen consistir en un ciclo repetitivo de unos 10 segundos en los que habla el usuario, seguidos de una llamada a la API de TTS para unos 150 caracteres y, después, unos 10 segundos de reproducción de audio para el usuario. Por tanto, cada usuario debe seguir el patrón de realizar una llamada a la API de Texto a Voz mediante websocket para 150 caracteres de texto cada 20 segundos, introduciendo una pequeña cantidad de aleatoriedad en el periodo de espera y en el número de caracteres solicitados. La prueba consistiría en generar un usuario por segundo hasta llegar a 100 y, a continuación, realizar pruebas durante 10 minutos en total para comprobar la estabilidad general.

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