WebSocket ou REST
En cas de doute, commencez par REST. Il suffit d’un POST, et le corps de la
réponse est l’audio. Passez au WebSocket lorsque la latence ou le besoin d’une
entrée en streaming font de REST le goulot d’étranglement.
Ce que les deux transports ont en commun
- Voix : n’importe quel
voice_idde la bibliothèque de voix fonctionne sur les deux. Les candidats Voice Design font exception : REST uniquement, jusqu’à leur conversion. - Formats de sortie : PCM, WAV, Opus et les codecs de téléphonie (
ulaw_8000,alaw_8000). - Paramètres de voix :
temp,padding_bonusetrewrite_rules, tous passés dansjson_config. Consultez Paramètres de voix.
Ce qui est propre à chaque transport
- Les balises
<flush>et<break time="..." />sont traitées par le modèle sur les deux transports, mais ne sont vraiment utiles que lorsque vous envoyez le texte en flux via le WebSocket. - WebSocket uniquement : contrôles du flux dans le message de setup (
send_setup_on_start,wait_for_ready_on_start), multiplexage,flushen cours de flux, tokens navigateur, dictionnaires de prononciation (pronunciation_id). Consultez Cycle de vie WebSocket. En REST, utilisezrewrite_rulesdansjson_configpour contrôler la prononciation. - REST uniquement : l’option
only_audio, pour choisir entre des octets audio bruts et un flux NDJSON qui reproduit le protocole WebSocket.
Étapes suivantes
Utiliser l'API WebSocket
Utilisation via le SDK ou directement en WebSocket, sortie en streaming, flush, horodatages.
Utiliser l'API REST
Synthèse ponctuelle avec un seul POST HTTP.
Du LLM au TTS
Envoyez en flux le texte généré vers le TTS tout en préservant une prosodie naturelle.
Paramètres de voix
Vitesse, température et règles de réécriture.
Bibliothèque de voix
Parcourez les voix phares ou créez vos propres clones.