client_req_id ; le serveur recopie cette valeur dans les réponses afin
que votre client puisse renvoyer l’audio, le texte, la VAD et les
événements de fin vers le bon appelant.
C’est utile si vous voulez éviter d’ouvrir un nouveau WebSocket pour
chaque énoncé court, ou si un serveur doit traiter en parallèle de
nombreuses requêtes TTS à faible latence.
Fonctionnement du multiplexage
Pour exécuter des requêtes simultanées sur le même socket :
- Définissez
close_ws_on_eos: falsedans chaquesetup. - Générez un
client_req_idunique par requête logique. - Incluez ce même
client_req_iddans lesetup, les messages d’entrée et leend_of_stream. - Routez les réponses selon leur
client_req_id.
client_req_id alors que la requête précédente
est encore active, le serveur renvoie une erreur de protocole.
Exemple TTS
audio contient des octets déjà
décodés. Si vous communiquez directement avec le WebSocket, audio est
encodé en base64.
Échanges sur le fil
Client
Server
Remarques sur la transcription
Le même mécanismeclient_req_id existe sur les WebSockets de
transcription. Ne l’utilisez que si chaque source audio constitue un
flux logique distinct et que votre client sait router chaque fragment
audio, chaque flush et chaque end_of_stream vers la bonne requête.
Fermer un socket réutilisable
Une fois toutes les requêtes logiques terminées, envoyez unend_of_stream sans client_req_id pour fermer le socket réutilisable :
Gestion des erreurs
Les erreurs incluentclient_req_id lorsque le serveur peut identifier
la requête logique concernée :
error comme définitive pour la requête logique
concernée. Selon l’erreur et la présence d’autres sessions actives, le
WebSocket peut se fermer une fois les requêtes en cours terminées.
Voir aussi
Cycle de vie WebSocket
Setup, ready, entrée, flush, fin et erreurs.
Des tokens LLM à la synthèse vocale en streaming
Diffusez du texte généré tout en préservant la prosodie.