Skip to main content
Le multiplexage vous permet d’envoyer plusieurs requêtes indépendantes sur une seule connexion WebSocket. Chaque requête logique reçoit un 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 :
  1. Définissez close_ws_on_eos: false dans chaque setup.
  2. Générez un client_req_id unique par requête logique.
  3. Incluez ce même client_req_id dans le setup, les messages d’entrée et le end_of_stream.
  4. Routez les réponses selon leur client_req_id.
Si vous réutilisez un client_req_id alors que la requête précédente est encore active, le serveur renvoie une erreur de protocole.

Exemple TTS

Avec le SDK Python, chaque message 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
Les réponses peuvent arriver entrelacées. Ne partez pas du principe que la première requête se termine avant que la seconde commence à renvoyer de l’audio.

Remarques sur la transcription

Le même mécanisme client_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.
Pour la plupart des applications de microphone en direct ou de téléphonie, un WebSocket de transcription par flux de locuteur en direct est plus simple à appréhender. Ne multiplexez la transcription que si le coût des connexions compte et que vous disposez de tests de routage rigoureux.

Fermer un socket réutilisable

Une fois toutes les requêtes logiques terminées, envoyez un end_of_stream sans client_req_id pour fermer le socket réutilisable :
Si des requêtes sont encore en cours, le serveur ferme le socket une fois qu’elles sont terminées. Si aucune requête n’est active, il le ferme immédiatement.

Gestion des erreurs

Les erreurs incluent client_req_id lorsque le serveur peut identifier la requête logique concernée :
Considérez une 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.