Modelos

Modelos principais

Text to Speech

Speech to Text

Música

Visão geral dos modelos

A API da ElevenLabs oferece diversos modelos de áudio otimizados para diferentes casos de uso, níveis de qualidade e requisitos de desempenho.

Modelos descontinuados

Eleven v4

O Eleven v4 é nosso modelo de síntese de fala de última geração, oferecendo nosso áudio de maior qualidade, expressividade e controle sobre a interpretação das vozes. O Eleven v4 oferece suporte à clonagem de voz de alta fidelidade, com preservação confiável do locutor em gerações de texto longas.

Este modelo funciona bem nos seguintes cenários:

• Locuções de personagens: Ideal para jogos e animações devido à sua amplitude emocional.
• Diálogo emocional: Gere diálogos naturais e realistas com ampla variedade emocional e compreensão contextual.
• Produção de audiolivros: Perfeito para narrações longas com interpretação emocional complexa.
• Projetos multilíngues: Mantém uma qualidade de voz consistente ao alternar entre idiomas.

O Eleven v4 está disponível pela API de Text to Dialogue.

Idiomas compatíveis

A família de modelos Eleven v4 oferece suporte a mais de 90 idiomas, incluindo:

Africâner (afr), Amárico (amh), Árabe (ara), Armênio (hye), Assamese (asm), Asturiano (ast), Azerbaijano (aze), Bielorrusso (bel), Bengali (ben), Bósnio (bos), Búlgaro (bul), Birmanês (mya), Cantonês (yue), Catalão (cat), Cebuano (ceb), Croata (hrv), Tcheco (ces), Dinamarquês (dan), Holandês (nld), Inglês (eng), Estoniano (est), Filipino (fil), Finlandês (fin), Francês (fra), Fula/Pulaar (ful), Galego (glg), Georgiano (kat), Alemão (deu), Grego (ell), Guzerate (guj), Hauçá (hau), Hebraico (heb), Hindi (hin), Húngaro (hun), Islandês (isl), Indonésio (ind), Italiano (ita), Japonês (jpn), Javanês (jav), Kamba (kam), Canarês (kan), Cazaque (kaz), Coreano (kor), Quirguiz (kir), Lao (lao), Letão (lav), Lingala (lin), Lituano (lit), Luganda (lug), Luxemburguês (ltz), Macedônio (mkd), Malaio (msa), Malaiala (mal), Maltês (mlt), Chinês mandarim (cmn), Maori (mri), Marata (mar), Mongol (mon), Nepali (nep), Norueguês bokmål (nob), Occitano (oci), Odia (ori), Pachto (pus), Persa (fas), Polonês (pol), Português, Brasil (por), Punjabi (pan), Romeno (ron), Russo (rus), Sérvio (srp), Shona (sna), Sindi (snd), Eslovaco (slk), Esloveno (slv), Somali (som), Curdo sorani (ckb), Espanhol, América Latina (spa), Suaíli (swa), Sueco (swe), Tadjique (tgk), Tâmil (tam), Telugu (tel), Tailandês (tha), Turco (tur), Ucraniano (ukr), Urdu (urd), Uzbeque (uzb), Vietnamita (vie), Galês (cym), Wolof (wol), Zulu (zul).

Eleven v4 Turbo

O Eleven v4 Turbo é nosso modelo de última geração para síntese de fala em tempo real, oferecendo áudio de alta qualidade, expressividade e controle sobre a interpretação das vozes. O Eleven v4 Turbo oferece suporte à clonagem de voz de alta fidelidade e entrega resultados com latência mediana de inferência de aproximadamente 100 ms.

Este modelo funciona bem nos seguintes cenários:

• Agentes de suporte: Impulsione agentes de voz que resolvem dúvidas de clientes em tempo real.
• Assistentes de IA: Gere diálogos naturais e realistas com ampla variedade emocional e compreensão contextual.
• Personagens interativos: Excelente para experiências de áudio com personagens expressivos.

O Eleven v4 Turbo está disponível pelo WebSocket de Text to Dialogue.

Idiomas compatíveis

A família de modelos Eleven v4 oferece suporte a mais de 90 idiomas, incluindo:

Africâner (afr), Amárico (amh), Árabe (ara), Armênio (hye), Assamese (asm), Asturiano (ast), Azerbaijano (aze), Bielorrusso (bel), Bengali (ben), Bósnio (bos), Búlgaro (bul), Birmanês (mya), Cantonês (yue), Catalão (cat), Cebuano (ceb), Croata (hrv), Tcheco (ces), Dinamarquês (dan), Holandês (nld), Inglês (eng), Estoniano (est), Filipino (fil), Finlandês (fin), Francês (fra), Fula/Pulaar (ful), Galego (glg), Georgiano (kat), Alemão (deu), Grego (ell), Guzerate (guj), Hauçá (hau), Hebraico (heb), Hindi (hin), Húngaro (hun), Islandês (isl), Indonésio (ind), Italiano (ita), Japonês (jpn), Javanês (jav), Kamba (kam), Canarês (kan), Cazaque (kaz), Coreano (kor), Quirguiz (kir), Lao (lao), Letão (lav), Lingala (lin), Lituano (lit), Luganda (lug), Luxemburguês (ltz), Macedônio (mkd), Malaio (msa), Malaiala (mal), Maltês (mlt), Chinês mandarim (cmn), Maori (mri), Marata (mar), Mongol (mon), Nepali (nep), Norueguês bokmål (nob), Occitano (oci), Odia (ori), Pachto (pus), Persa (fas), Polonês (pol), Português, Brasil (por), Punjabi (pan), Romeno (ron), Russo (rus), Sérvio (srp), Shona (sna), Sindi (snd), Eslovaco (slk), Esloveno (slv), Somali (som), Curdo sorani (ckb), Espanhol, América Latina (spa), Suaíli (swa), Sueco (swe), Tadjique (tgk), Tâmil (tam), Telugu (tel), Tailandês (tha), Turco (tur), Ucraniano (ukr), Urdu (urd), Uzbeque (uzb), Vietnamita (vie), Galês (cym), Wolof (wol), Zulu (zul).

Eleven v3

O Eleven v3 é nosso modelo de síntese de fala da geração anterior, que produz fala natural e realista com ampla variedade emocional e compreensão contextual em vários idiomas.

Com o Eleven v3, apresentamos uma nova API de Text to Dialogue, que permite gerar diálogos naturais e realistas com ampla variedade emocional e compreensão contextual em vários idiomas. O Eleven v3 também pode ser usado com a API de Text to Speech para gerar fala natural e realista com ampla variedade emocional e compreensão contextual em vários idiomas.

Leia mais sobre a API de Text to Dialogue aqui.

Idiomas compatíveis

O modelo Eleven v3 oferece suporte a mais de 70 idiomas, incluindo:

Africâner (afr), Árabe (ara), Armênio (hye), Assamese (asm), Azerbaijano (aze), Bielorrusso (bel), Bengali (ben), Bósnio (bos), Búlgaro (bul), Catalão (cat), Cebuano (ceb), Chichewa (nya), Croata (hrv), Tcheco (ces), Dinamarquês (dan), Holandês (nld), Inglês (eng), Estoniano (est), Filipino (fil), Finlandês (fin), Francês (fra), Galego (glg), Georgiano (kat), Alemão (deu), Grego (ell), Guzerate (guj), Hauçá (hau), Hebraico (heb), Hindi (hin), Húngaro (hun), Islandês (isl), Indonésio (ind), Irlandês (gle), Italiano (ita), Japonês (jpn), Javanês (jav), Canarês (kan), Cazaque (kaz), Quirguiz (kir), Coreano (kor), Letão (lav), Lingala (lin), Lituano (lit), Luxemburguês (ltz), Macedônio (mkd), Malaio (msa), Malaiala (mal), Chinês mandarim (cmn), Marata (mar), Nepali (nep), Norueguês (nor), Pachto (pus), Persa (fas), Polonês (pol), Português (por), Punjabi (pan), Romeno (ron), Russo (rus), Sérvio (srp), Sindi (snd), Eslovaco (slk), Esloveno (slv), Somali (som), Espanhol (spa), Suaíli (swa), Sueco (swe), Tâmil (tam), Telugu (tel), Tailandês (tha), Turco (tur), Ucraniano (ukr), Urdu (urd), Vietnamita (vie), Galês (cym).

Eleven v3 Conversational

O Eleven v3 Conversational é nosso modelo de geração anterior para síntese de fala em tempo real. Ele produz fala natural e realista com ampla variedade emocional e compreensão contextual em vários idiomas.

Com o Eleven v3 Conversational, apresentamos um novo WebSocket de Text to Dialogue, que permite gerar diálogos naturais e realistas com ampla variedade emocional e compreensão contextual em vários idiomas.

Com o Eleven v3 Conversational, apresentamos um novo WebSocket de Text to Dialogue, que permite gerar diálogos naturais e realistas com ampla variedade emocional e compreensão contextual em vários idiomas.

Leia mais sobre o WebSocket de Text to Dialogue aqui.

Idiomas compatíveis

O modelo Eleven v3 oferece suporte a mais de 70 idiomas, incluindo:

Africâner (afr), Árabe (ara), Armênio (hye), Assamese (asm), Azerbaijano (aze), Bielorrusso (bel), Bengali (ben), Bósnio (bos), Búlgaro (bul), Catalão (cat), Cebuano (ceb), Chichewa (nya), Croata (hrv), Tcheco (ces), Dinamarquês (dan), Holandês (nld), Inglês (eng), Estoniano (est), Filipino (fil), Finlandês (fin), Francês (fra), Galego (glg), Georgiano (kat), Alemão (deu), Grego (ell), Guzerate (guj), Hauçá (hau), Hebraico (heb), Hindi (hin), Húngaro (hun), Islandês (isl), Indonésio (ind), Irlandês (gle), Italiano (ita), Japonês (jpn), Javanês (jav), Canarês (kan), Cazaque (kaz), Quirguiz (kir), Coreano (kor), Letão (lav), Lingala (lin), Lituano (lit), Luxemburguês (ltz), Macedônio (mkd), Malaio (msa), Malaiala (mal), Chinês mandarim (cmn), Marata (mar), Nepali (nep), Norueguês (nor), Pachto (pus), Persa (fas), Polonês (pol), Português (por), Punjabi (pan), Romeno (ron), Russo (rus), Sérvio (srp), Sindi (snd), Eslovaco (slk), Esloveno (slv), Somali (som), Espanhol (spa), Suaíli (swa), Sueco (swe), Tâmil (tam), Telugu (tel), Tailandês (tha), Turco (tur), Ucraniano (ukr), Urdu (urd), Vietnamita (vie), Galês (cym).

Multilingual v2

Eleven Multilingual v2 é um modelo de síntese de voz com percepção emocional de uma geração anterior. Ele produz fala natural e realista, com ampla expressividade emocional e compreensão contextual em vários idiomas.

O modelo oferece qualidade de voz e personalidade consistentes em todos os idiomas compatíveis, preservando as características únicas e o sotaque do locutor.

Este modelo se destaca em cenários que exigem fala de alta qualidade e nuances emocionais:

• Locuções de personagens: Ideal para jogos e animações devido à sua expressividade emocional.
• Conteúdo profissional: Muito adequado para vídeos corporativos e materiais de e-learning.
• Projetos multilíngues: Mantém uma qualidade de voz consistente ao alternar entre idiomas.
• Qualidade estável: Produz áudio consistente e de alta qualidade.

Embora tenha maior latência e custo por caractere do que os modelos Flash, oferece qualidade superior para projetos em que uma fala realista é importante.

Nossos modelos multilíngues v2 oferecem suporte a 29 idiomas:

Inglês (EUA, Reino Unido, Austrália, Canadá), Japonês, Chinês, Alemão, Hindi, Francês (França, Canadá), Coreano, Português (Brasil, Portugal), Italiano, Espanhol (Espanha, México), Indonésio, Holandês, Turco, Filipino, Polonês, Sueco, Búlgaro, Romeno, Árabe (Arábia Saudita, Emirados Árabes Unidos), Tcheco, Grego, Finlandês, Croata, Malaio, Eslovaco, Dinamarquês, Tâmil, Ucraniano e Russo.

Flash v2.5

Eleven Flash v2.5 é nosso modelo de síntese de voz mais rápido, desenvolvido para aplicações em tempo real e a Agents Platform. Ele oferece fala de alta qualidade com latência ultrabaixa (~75ms†) em 32 idiomas.

O modelo equilibra velocidade e qualidade, tornando-se ideal para aplicações interativas, ao mesmo tempo que mantém uma saída com som natural e características de voz consistentes entre os idiomas.

Este modelo é especialmente adequado para:

• Agents Platform: Perfeito para agentes de voz e chatbots em tempo real.
• Aplicações interativas: Ideal para jogos e aplicações que exigem resposta imediata.
• Processamento em larga escala: Eficiente para conversão em massa de texto em fala.

Com seu preço mais baixo para gerações via API e latência de 75ms, o Flash v2.5 é a opção econômica para quem precisa de síntese de voz rápida e confiável em vários idiomas.

O Flash v2.5 oferece suporte a 32 idiomas — todos os idiomas dos modelos v2, além de:

Húngaro, Norueguês e Vietnamita

Considerações

Guia de seleção de modelos

Para orientações sobre qual modelo atende melhor aos seus requisitos e caso de uso, consulte o guia de seleção de modelos.

Limites de caracteres

O número máximo de caracteres aceitos em uma única solicitação de texto em fala varia conforme o modelo.

Scribe v2

Scribe v2 é nosso modelo de reconhecimento de fala de última geração, desenvolvido para transcrição precisa em mais de 90 idiomas. Ele fornece marcações de tempo precisas no nível da palavra e recursos avançados, como diarização de locutores e marcação dinâmica de áudio.

Este modelo se destaca em cenários que exigem conversão precisa de fala em texto:

• Serviços de transcrição: Perfeito para converter conteúdo de áudio e vídeo em texto
• Documentação de reuniões: Ideal para registrar e documentar conversas
• Análise de conteúdo: Muito adequado para processamento e análise de conteúdo de áudio
• Reconhecimento multilíngue: Compatível com transcrição precisa em mais de 90 idiomas

Recursos principais:

• Transcrição precisa com marcações de tempo no nível da palavra
• Diarização de locutores para áudio com vários falantes
• Marcação dinâmica de áudio para mais contexto
• Compatibilidade com mais de 90 idiomas
• Detecção de entidades
• Inserção de termos-chave
• Edição de transcrições

Leia mais sobre o Scribe v2 aqui.

Scribe v2 Realtime

Scribe v2 Realtime, nosso modelo mais rápido e preciso de reconhecimento de fala ao vivo, oferece precisão de última geração em mais de 90 idiomas com latência ultrabaixa de 150ms.

Este modelo se destaca em casos de uso conversacionais:

• Transcrição de reuniões ao vivo: Perfeito para transcrição em tempo real
• Agentes de IA: Ideal para conversas ao vivo
• Reconhecimento multilíngue: Compatível com transcrição precisa em mais de 90 idiomas e reconhecimento automático de idioma

Recursos principais:

• Latência ultrabaixa: receba transcrições parciais em ~150 milissegundos
• Compatibilidade com streaming: envie áudio em partes enquanto recebe transcrições em tempo real
• Vários formatos de áudio: compatibilidade com PCM (de 8kHz a 48kHz) e codificação μ-law
• Detecção de atividade de voz (VAD): segmentação automática de fala com base na detecção de silêncio
• Controle manual de confirmação: controle total sobre quando finalizar segmentos da transcrição
• Detecção de entidades
• Edição de transcrições

Leia mais sobre o Scribe v2 Realtime aqui.

Scribe v2 Medical

Scribe v2 Medical é um modelo de reconhecimento de fala em lote especializado em áudio médico e clínico. É um Finetune do Scribe v2 que melhora o reconhecimento de nomes de medicamentos, anatomia, patologia e ditado clínico, mantendo a precisão do Scribe v2 em fala cotidiana. Ele usa a mesma API de Speech to Text do Scribe v2 e tem a mesma cobrança. Passe scribe_v2_medical como model_id.

Este modelo é adequado para:

• Documentação clínica: Consultas presenciais e anotações em que termos médicos surgem durante a conversa
• Ditado: Sequências densas de medicamentos, dosagens e achados
• Chamadas de admissão e coordenação: Pacientes descrevendo suas próprias condições, muitas vezes por telefone
• Fluxos de trabalho de conformidade: Combine com a detecção de entidades para categorias de PHI

Recursos principais:

• Mesma estrutura de solicitação do Scribe v2 (keyterms, entity_detection, no_verbatim, diarização, marcações de tempo)
• Melhor reconhecimento de nomes de medicamentos e termos de anatomia e patologia
• Sem regressão na fala cotidiana em comparação ao Scribe v2
• Compatibilidade com mais de 90 idiomas
• Diarização de locutores para áudio com vários falantes
• Marcação dinâmica de áudio
• Detecção de entidades, incluindo categorias de PHI

Scribe v2 Medical é um modelo em lote. Para transcrição ao vivo, use o Scribe v2 Realtime.

O Scribe v2 Medical é elegível para HIPAA, com Acordos de Associado Comercial disponíveis para clientes Enterprise, além do Modo de Retenção Zero (ZRM). Com o ZRM ativado, a entrada de áudio e a saída de texto são excluídas imediatamente após a conclusão de cada solicitação. A ElevenLabs não retém nada, e sua aplicação recebe a resposta completa da API e mantém as transcrições sob seus próprios controles.

Leia mais sobre Speech to Text aqui.

Eleven Music

Eleven Music é nosso modelo de geração de música com qualidade de estúdio. Ele permite gerar músicas de qualquer estilo usando prompts em linguagem natural.

Este modelo é excelente para os seguintes cenários:

• Trilhas sonoras para jogos: Crie trilhas imersivas para jogos
• Música de fundo para podcasts: Aprimore podcasts com música profissional
• Marketing: Adicione música de fundo a vídeos publicitários

Recursos principais:

• Controle completo sobre gênero, estilo e estrutura
• Vocais ou apenas instrumental
• Multilíngue, incluindo inglês, espanhol, alemão, japonês e mais
• Edite o som e a letra de seções individuais ou da música inteira

Leia mais sobre o Eleven Music aqui.

Simultaneidade e prioridade

Seu plano de assinatura determina quantas solicitações podem ser processadas simultaneamente e o nível de prioridade das suas solicitações na fila. O Speech to Text tem um limite de simultaneidade maior. Quando o limite de simultaneidade é atingido, as solicitações seguintes são processadas em uma fila junto com solicitações de menor prioridade. Na prática, isso normalmente adiciona apenas cerca de 50 ms de latência.

Os cabeçalhos da resposta incluem current-concurrent-requests e maximum-concurrent-requests, que você pode usar para monitorar sua simultaneidade.

Solicitações da API por minuto vs. solicitações simultâneas

É importante entender que solicitações da API por minuto e solicitações simultâneas são métricas diferentes que dependem dos seus padrões de uso.

As solicitações da API por minuto podem ser diferentes das solicitações simultâneas, pois isso depende da duração de cada solicitação e de como elas são agrupadas.

Exemplo 1: Solicitações espaçadas Se você tivesse 180 solicitações por minuto, cada uma levando 1 segundo para ser concluída, e as enviasse com 0,33 segundo de intervalo, o máximo de solicitações simultâneas seria 3 e a média também seria 3, pois sempre haveria 3 em andamento.

Exemplo 2: Solicitações em lote No entanto, se você tivesse um padrão de uso diferente, como 180 solicitações por minuto que levassem 3 segundos cada para serem concluídas, mas todas fossem disparadas de uma vez, o máximo de solicitações simultâneas seria 180 e a média seria 9 (nos primeiros 3 segundos do minuto, houve 180 solicitações de uma vez; nos últimos 57 segundos, houve 0 solicitações).

Como nosso sistema considera a simultaneidade, as solicitações por minuto importam menos do que o tempo de duração de cada solicitação e o padrão de quando elas são enviadas.

A forma como as solicitações aos endpoints são feitas afeta os limites de simultaneidade:

• Com HTTP, cada solicitação conta individualmente para seu limite de simultaneidade.
• Com o WebSocket de Text to Speech, apenas o tempo em que nosso modelo está gerando áudio conta para seu limite de simultaneidade. Isso significa que, na maior parte do tempo, um websocket aberto não conta para seu limite de simultaneidade.
• Os WebSockets de Text to Dialogue funcionam de forma diferente: cada conexão aberta reserva uma sessão de diálogo de um pool separado enquanto permanecer aberta, e o áudio gerado pela conexão não conta para seu limite padrão de simultaneidade. Isso foi criado para facilitar o entendimento: uma conexão é uma sessão, e seus limites de sessões de diálogo são dimensionados para se adaptar a essa nova metodologia de simultaneidade. Consulte simultaneidade do Text to Dialogue.

Como entender os limites de simultaneidade

O limite de simultaneidade associado ao seu plano não deve ser interpretado como o número máximo de conversas simultâneas, chamadas telefônicas, locuções de personagens etc. que podem ser atendidas de uma vez. O número real depende de vários fatores, incluindo as vozes IA específicas usadas e as características do caso de uso.

Como regra geral, um limite de simultaneidade de 5 normalmente pode atender a aproximadamente 100 transmissões de áudio simultâneas.

Isso se deve à velocidade com que o áudio é gerado em relação ao tempo necessário para processar a solicitação de TTS. O diagrama abaixo é um exemplo de como 4 chamadas simultâneas com usuários diferentes podem ser atendidas usando apenas 2 solicitações simultâneas.

Se você exceder os limites de simultaneidade do seu plano e estiver no plano Enterprise, as solicitações ao modelo ainda poderão ser concluídas, embora mais lentamente, conforme a capacidade disponível e sem garantia.

Simultaneidade do Text to Dialogue

As solicitações de Text to Dialogue são medidas de duas formas diferentes, dependendo de como você chama a API:

• Os endpoints HTTP (Criar diálogo e Transmitir diálogo) contam para o limite padrão de simultaneidade do seu plano enquanto o áudio está sendo gerado, como qualquer outra solicitação de Text to Speech.
• Os endpoints WebSocket, como o WebSocket de Text to Dialogue, são medidos como sessões de diálogo. Uma conexão aberta mantém uma sessão de diálogo enquanto permanecer aberta, independentemente de o áudio estar sendo gerado no momento.

A medição baseada em sessões simplifica o planejamento de capacidade: uma conexão é uma sessão, portanto seu uso não varia conforme a atividade de geração. Como uma sessão é mantida durante toda a conexão, e não apenas enquanto o áudio está sendo gerado, seus limites de sessões de diálogo são dimensionados para se adaptar a essa nova metodologia de simultaneidade.

Se você abrir uma conexão enquanto todas as sessões de diálogo do seu workspace estiverem em uso, a nova conexão será rejeitada com um erro too_many_concurrent_requests. Para liberar sessões, feche as conexões que você não precisa mais — uma conexão também é fechada automaticamente após 20 segundos de inatividade, a menos que você envie mensagens keep_alive.

Para monitorar sessões de diálogo, abra Developers na parte inferior da barra lateral do painel, selecione a aba Analytics e veja a métrica Concurrent requests na visualização de uso. As sessões de diálogo são informadas em uma série própria, TTD Websocket Sessions, separada das suas outras solicitações simultâneas.

Teste de carga dos limites de simultaneidade

Testes de carga podem ser úteis para identificar problemas de escalabilidade no lado do cliente e verificar se os limites de simultaneidade estão configurados corretamente para seu caso de uso.

Recomendamos fortemente testar fluxos de trabalho de ponta a ponta o mais próximo possível do uso real. Simular e medir quantos usuários podem ser atendidos é a metodologia recomendada para isso. É importante:

• Simular usuários, não solicitações brutas
• Simular o comportamento típico do usuário, como esperar a reprodução do áudio, a fala do usuário ou a transcrição terminarem antes de fazer solicitações
• Aumentar o número de usuários lentamente ao longo de alguns minutos
• Introduzir aleatoriedade nos tempos das solicitações e no tamanho delas
• Registrar métricas de latência e todos os códigos de erro retornados pela API

Por exemplo, para testar um sistema de agentes desenvolvido para atender a 100 conversas simultâneas, você criaria até 100 “usuários” individuais, cada um simulando uma conversa. As conversas normalmente consistem em um ciclo repetido de cerca de 10 segundos de fala do usuário, seguido de uma chamada à API de TTS para cerca de 150 caracteres, seguida de cerca de 10 segundos de reprodução de áudio para o usuário. Portanto, cada usuário deve seguir o padrão de fazer uma chamada à API de Text-to-Speech por websocket para 150 caracteres de texto a cada 20 segundos, com uma pequena quantidade de aleatoriedade introduzida no período de espera e no número de caracteres solicitados. O teste consistiria em iniciar um usuário por segundo até haver 100 e, depois, testar por 10 minutos no total para avaliar a estabilidade geral.

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