Skip to main content
Le modèle de transcription de Gradium transcrit l’audio en temps réel via un WebSocket, avec une détection d’activité vocale (VAD) sémantique et un flush à la demande pour une gestion des tours de parole à faible latence. Ce guide couvre le streaming avec le SDK Python.

Transcription ponctuelle d'un fichier complet ?

Si vous disposez déjà d’un audio préenregistré, l’endpoint REST POST suffit en un seul appel HTTP : consultez le guide REST.

Démarrage rapide

Le chemin le plus court : ouvrez un gestionnaire de contexte stt_realtime, envoyez des fragments audio, puis itérez pour recevoir les transcriptions.
Audio attendu : PCM mono 24 kHz, 16 bits signé, en fragments de 1920 échantillons (80 ms). D’autres formats sont pris en charge, voir Paramètres de configuration.

Choisir l’API du SDK

Le SDK Python propose deux façons de faire du streaming STT via l’endpoint WebSocket. Toutes deux communiquent avec wss://api.gradium.ai/api/speech/asr : choisissez selon la nature de votre source audio. stt_stream est un unique appel asynchrone qui consomme votre itérable audio et renvoie un STTStream dont la méthode iter_text() produit des segments TextWithTimestamps. stt_realtime est un gestionnaire de contexte asynchrone : vous envoyez les fragments avec send_audio() et itérez sur le même objet pour recevoir tous les types de messages, text, step de VAD, end_text, flushed. La configuration se passe sous forme de dict pour stt_stream et d’arguments nommés pour stt_realtime. Le message setup envoyé sur le réseau est le même dans les deux cas.

Mode pull : stt_stream

Utilisez stt_stream lorsque l’audio est déjà disponible, par exemple pour transcrire un fichier ou un buffer complet en mémoire. La fonction consomme votre itérable audio et produit des segments de texte finalisés.
iter_text() ne conserve que les segments de texte et produit des objets TextWithTimestamps (text, start_s, stop_s). Pour observer les messages de VAD ou flushed, utilisez stt_realtime ci-dessous.

Mode push en temps réel : stt_realtime

Utilisez stt_realtime lorsque l’audio est produit en direct (micro, téléphonie, agent conversationnel) et que vous devez réagir aux événements de VAD ou de flush dès leur arrivée. C’est un gestionnaire de contexte asynchrone : envoyez l’audio avec send_audio() et itérez sur le même objet pour recevoir tous les types de messages.
La configuration se passe en arguments nommés (model_name, input_format, json_config, …). Voir Paramètres de configuration ci-dessous.

Paramètres de configuration

  • model_name : le modèle STT à utiliser (par défaut : "default").
  • input_format : format audio de l’entrée. Valeurs prises en charge :
    • "pcm" : PCM brut, 24 kHz, 16 bits signé little-endian, mono. Envoyez des fragments de 1920 échantillons (80 ms) pour de meilleurs résultats.
    • "pcm_8000", "pcm_16000", "pcm_22050", "pcm_24000", "pcm_44100", "pcm_48000" : PCM brut à la fréquence d’échantillonnage indiquée (16 bits signé little-endian, mono).
    • "wav" : un fichier WAV valide contenant des données PCM (AudioFormat = 1 dans l’en-tête WAV). Les échantillons de 16, 24 et 32 bits sont pris en charge.
    • "opus" : flux Opus encapsulé dans un conteneur Ogg.
    • "ulaw_8000" (alias "mulaw_8000") : PCM encodé en mu-law à 8 kHz.
    • "alaw_8000" : PCM encodé en A-law à 8 kHz.
  • json_config : options STT avancées. Passez un dict avec le SDK Python, ou un objet/une chaîne JSON dans le message setup du WebSocket brut. Les clés courantes sont language, target_language, temp, padding_bonus et delay_in_frames.
Toute valeur non reconnue provoque une erreur serveur.

Exemple de langue et de délai

Utilisez json_config.language pour définir la langue de l’audio ("any" si elle est inconnue), et json_config.delay_in_frames pour arbitrer entre latence et contexte. Chaque trame dure 80 ms. Des valeurs de délai faibles rendent le modèle plus réactif ; des valeurs élevées lui donnent plus de contexte avant d’émettre du texte.
Pour les modèles STT de traduction, utilisez target_language ou language pour définir la langue de la transcription en sortie. Voir Paramètres de transcription.

Types de messages

Lorsque vous itérez sur une session stt_realtime, vous recevez tous les messages envoyés par le serveur. Les types utiles pour la transcription :
  • text : un segment de texte transcrit, avec un horodatage start_s.
  • end_text : finalise le segment text précédent avec un horodatage stop_s. Voir Horodatages.
  • step : informations de détection d’activité vocale émises toutes les 80 ms. Voir Détection d’activité vocale (VAD).
  • flushed : confirmation que tout l’audio envoyé avant un send_flush() a été traité. Voir Flush.
  • end_of_stream : message final après send_eos().
Pour le schéma au niveau du protocole (types de champs complets et JSON échangé), consultez la référence STT WebSocket.
stt_stream n’expose que les segments de texte finalisés via iter_text(). Pour observer les messages step, end_text ou flushed, utilisez stt_realtime.

Horodatages

Chaque message text contient un champ start_s, l’instant (en secondes) dans l’audio d’entrée où commence le segment transcrit. Lorsque le segment est finalisé, le serveur émet un message end_text avec le stop_s correspondant :
Associez text et end_text par stream_id pour reconstituer les triplets (text, start_s, stop_s) de chaque segment. Les horodatages sont émis à la granularité du segment. Pour des positions plus fines au niveau du mot ou du caractère, déduisez-les du texte du segment.

Détection d’activité vocale (VAD)

Le WebSocket STT de Gradium émet un message step toutes les 80 ms contenant des prédictions de VAD sémantique sur plusieurs horizons : pour chaque horizon (en secondes), le modèle indique la probabilité que le locuteur reste silencieux pendant toute cette fenêtre. Plus l’horizon est long, plus l’affirmation est forte. C’est plus informatif qu’un simple indicateur voisé/non voisé, et c’est conçu pour la gestion des tours de parole dans les systèmes conversationnels.

Détecter la fin d’un tour de parole

Comme point de départ, nous recommandons d’observer l’horizon de 1 s, 2 s ou 3 s et de déclencher lorsque la probabilité d’inactivité dépasse 0,5 :
Ajustez l’horizon et le seuil selon votre application : des horizons plus courts ou des seuils plus bas rendent le système plus réactif mais peuvent couper la parole au locuteur ; des horizons plus longs ou des seuils plus élevés sont plus prudents.

Délai adaptatif

Le STT de Gradium n’est volontairement pas une boîte noire à latence fixe. L’option delay_in_frames contrôle la quantité de contexte audio que le modèle utilise avant d’émettre du texte. Chaque trame dure 80 ms, et le serveur renvoie la valeur active dans le champ ready.delay_in_frames. Des valeurs élevées donnent plus de contexte au modèle et peuvent améliorer la stabilité de la transcription. Des valeurs faibles réduisent la latence. Les valeurs acceptées sont les entiers de 7 à 55. La valeur par défaut est 10 si vous ne la définissez pas ; 16 est un bon point de départ si vous souhaitez un peu plus de stabilité pour des applications interactives.
À la fin d’un tour de parole, combinez la VAD sémantique avec send_flush() : lorsque votre application estime que le locuteur a terminé, flush demande à Gradium de traiter l’audio déjà envoyé, puis renvoie flushed avec le flush_id correspondant. En interne, le worker suit le délai ajusté après les événements de flush afin que les horodatages des segments restent alignés sur l’audio traité. Les messages step de VAD sont émis sur le transport WebSocket.

Flush

Vous pouvez forcer le serveur à traiter immédiatement tout l’audio en mémoire tampon avec send_flush(). C’est utile lorsque vous avez besoin des résultats de transcription sans attendre la cadence de traitement normale, par exemple lors d’une pause naturelle dans la conversation ou avant un changement de locuteur. Le serveur traite tout l’audio en attente, renvoie les résultats de texte en suspens, puis répond par un message flushed contenant le même flush_id que celui que vous avez fourni.

Options ajustables

Les modèles acceptent une configuration supplémentaire via json_config, notamment language, temp, padding_bonus et delay_in_frames. Utilisez delay_in_frames comme réglage de délai adaptatif pour arbitrer entre latence et qualité. Consultez Paramètres de transcription pour le tableau complet et la façon de passer json_config avec le SDK et en REST.

WebSocket direct

Si vous ne souhaitez pas utiliser le SDK gradium, par exemple parce que vous appelez l’API depuis un runtime autre que Python, ou que vous voulez un contrôle total sur les échanges, vous pouvez utiliser directement le protocole WebSocket. Les messages ont exactement la même forme que ceux envoyés par le SDK. Pour des tests interactifs depuis un terminal, wscat est le moyen le plus rapide de vérifier la connectivité et d’envoyer les messages à la main :
Pour un client sans le SDK, utilisez n’importe quelle bibliothèque WebSocket (ici websockets en Python) :
Pour le schéma complet des messages (chaque champ, chaque code d’erreur), consultez la référence STT WebSocket.

Étapes suivantes

Référence STT WebSocket

Schéma complet du protocole : chaque type de message, chaque champ, chaque code d’erreur.

REST en un seul appel

Transcrivez un fichier audio complet en une seule requête HTTP.

Exemples GitHub

Parcourez des exemples complets d’agents vocaux utilisant le STT et le TTS de Gradium.

Paramètres de transcription

language, temp, padding_bonus, delay_in_frames, et comment passer json_config.

Erreurs

Contrats d’erreur pour REST, WebSocket et les réponses en streaming.