Transmission audio et temporisations

Le service IBM Watson® Speech to Text vous permet de transmettre l'audio au service en une seule fois ou en flux audio vers le service. En ce qui concerne le flux audio, le service impose des temporisations pour garantir une activité de session continue.

Transmission audio

Avec l'interface WebSocket, les données audio sont diffusées au service via la connexion. Vous pouvez transmettre toutes les données en même temps ou transmettre les données en direct au fur et à mesure de leur disponibilité. Le service renvoie les résultats dès qu'ils sont disponibles.

Avec les interfaces HTTP, vous pouvez transmettre des données audio au service des deux manières suivantes :

Diffusion ponctuelle. Vous omettez l'en-tête de requête Transfer-Encoding et transmettez toutes les données audio au service en une seule fois.
Diffusion en continu. Vous définissez l'en-tête de la demande Transfer-Encoding avec la valeur chunked et diffusez les données en continu via une connexion permanente. Les données n'ont pas besoin d'exister en totalité lorsque vous les diffusez en continu vers le service. Vous pouvez transmettre les données au fur et à mesure de leur disponibilité. Le service n'envoie les résultats qu'une fois qu'il a reçu le bloc final, ce que vous pouvez indiquer en envoyant un bloc vide.

Pour plus d'informations, voir Transfer Codings dans IETF RFC 7320 HTTP/1.1: Syntaxe des messages et routage

Avec les interfaces HTTP, le service transcrit toujours le flux audio complet avant d'envoyer les résultats. Les résultats peuvent comprendre plusieurs éléments transcript pour indiquer que les expressions sont séparées par des pauses. Concaténez ces éléments transcript pour assembler la transcription complète.

Le service impose des délais d'attente pour une session de diffusion en continu. Il peut mettre fin à une session de ce type s'il détecte une période de silence prolongée ou s'il ne reçoit aucune donnée audio pendant une durée de 30 secondes. Pour plus d'informations sur les délais d'attente et savoir comment les éviter, voir Délais d'attente.

Exemple de transmission audio

L'exemple de demande suivant indique chunked pour que l'en-tête Transfer-Encoding utilise le mode de diffusion en continu. La connexion reste ouverte pour accepter d'autres blocs audio.

IBM Cloud

curl -X POST -u "apikey:{apikey}" \
--header "Content-Type: audio/flac" \
--header "Transfer-Encoding: chunked" \
--data-binary @{path}audio-file1.flac \
"{url}/v1/recognize"

IBM Cloud Pak for Data IBM Software Hub

curl -X POST \
--header "Authorization: Bearer {token}" \
--header "Content-Type: audio/flac" \
--header "Transfer-Encoding: chunked" \
--data-binary @{path}audio-file1.flac \
"{url}/v1/recognize"

Délais d'expiration

Lorsque vous initiez une session de diffusion en continu avec les méthodes de reconnaissance vocale HTTP ou WebSocket, le service met en place des délais d'attente d'inactivité et des délais d'attente de session. Lorsqu'un délai d'attente expire lors d'une session de diffusion en continu, le service ferme la connexion. Votre application doit être restaurée normalement après des fermetures de connexion éventuelles.

Lorsque vous diffusez des données audio en continu via HTTP, le service envoie un caractère espace dans sa réponse toutes les 20 secondes. Le service agit ainsi pour faciliter le fonctionnement en évitant l'application du délai d'attente d'inactivité de l'API REST HTTP fixé à 30 secondes. Pour conserver la connexion active pendant que la reconnaissance est en cours, le service continue à envoyer ce caractère espace jusqu'à la fin de sa transcription. Le caractère espace n'a aucun effet sur les données de réponse codées en JSON.

Le délai d'attente d'inactivité HTTP est différent du délai d'attente d'inactivité du service. L'interface WebSocket n'est pas soumise à ce délai d'attente HTTP.

Délai d'attente d'inactivité

L'expiration du délai d'attente d'inactivité (code de statut HTTP 400) se produit lorsque le service reçoit des données audio mais ne détecte qu'un silence prolongé ou des activités non vocales (sans parole) pendant une durée de 30 secondes. Le service envoie le message d'erreur No speech detected for 30s. Le délai d'attente d'inactivité s'avère utile, par exemple, pour mettre fin à une session lorsqu'un utilisateur s'éloigne d'un micro.

Le délai d'attente d'inactivité par défaut est fixé à 30 secondes. Vous pouvez remplacer cette valeur en utilisant le paramètre inactivity_timeout. Indiquez une valeur plus élevée pour augmenter le délai d'attente d'inactivité. Indiquez la valeur -1 pour définir un délai d'attente d'inactivité illimité. Vous êtes facturé pour toutes les données audio que vous envoyez au service, y compris le silence, par conséquent augmenter le délai d'attente d'inactivité peut induire des coûts supplémentaires pour une session de diffusion en continu qui n'enverrait que du silence.

Exemple de délai d'inactivité

L'exemple de demande suivant définit le délai d'attente d'inactivité à 60 secondes. La demande envoie un fichier initial pour commencer la session de diffusion en continu.

IBM Cloud

curl -X POST -u "apikey:{apikey}" \
--header "Transfer-Encoding: chunked" \
--header "Content-Type: audio/flac" \
--data-binary @{path}audio-file1.flac \
"{url}/v1/recognize?inactivity_timeout=60"

IBM Cloud Pak for Data IBM Software Hub

curl -X POST \
--header "Authorization: Bearer {token}" \
--header "Transfer-Encoding: chunked" \
--header "Content-Type: audio/flac" \
--data-binary @{path}audio-file1.flac \
"{url}/v1/recognize?inactivity_timeout=60"

Délai d'attente de session

Une expiration du délai d'attente de session (code de statut HTTP 408) se produit lorsque vous n'envoyez pas suffisamment de données audio pour garder une session de diffusion en continu active. Le service peut considérer une session comme étant inactive et déclencher une expiration du délai d'attente de session pour les raisons suivantes :

Vous n'envoyez pas au moins 15 secondes de données audio au service dans un créneau de 30 secondes.

Tant que vous n'avez pas envoyé le dernier tronçon pour indiquer la fin du flux, vous devez envoyer au moins 15 secondes de données audio toutes les 30 secondes. Ces données audio peuvent comporter du silence si vous avez défini le paramètre inactivity_timeout avec une valeur supérieure ou avec -1. Vous êtes facturé pour la durée des données audio que vous envoyez au service, y compris le silence.
Vous transmettez des données audio à une fréquence beaucoup plus lente qu'en temps réel.

Idéalement, vous allez initier une demande pour établir une session juste avant d'obtenir les données audio à transcrire. Vous conservez alors la session en envoyant des données audio à une fréquence proche du temps réel.

Vous n'avez pas besoin de vous soucier du délai d'attente de session après avoir envoyé le dernier tronçon pour indiquer la fin du flux audio. Le service continue à traiter les données audio jusqu'à ce qu'il renvoie les résultats de la transcription finale.

Lorsque vous transcrivez un flux audio long, le service peut prendre plus de 30 secondes pour traiter les données audio et générer une réponse. Il ne commence à calculer le délai d'attente de session qu'après avoir terminé le traitement de toutes les données audio qu'il a reçues. Le temps de traitement du service ne peut pas entraîner le dépassement du délai d'attente de session fixé à 30 secondes.

Par exemple, si vous effectuez une heure de transmission audio dans les 10 premières secondes d'une session, le service peut nécessiter 300 secondes pour traiter les données audio. Pour conserver cette session active, il vous faudra rajouter au moins 15 secondes d'audio supplémentaires, y compris du silence, au plus tard 340 secondes dans la session.

Dans cet exemple, si vous envoyez 15 secondes d'audio supplémentaires à la 100e seconde de la session, le service peut passer deux secondes de plus à traiter ces données audio. Dans ce cas, vous devrez transmettre 15 secondes d'audio supplémentaires au plus tard 342 secondes dans la session.

Ne vous fiez pas au temps de traitement ou à la réception des résultats pour déterminer si une session de diffusion en continu est inactive. Considérez que le service peut traiter toutes les données audio instantanément, et envoyez les données au service en conséquence. Si vous diffusez les données audio en temps réel, n'oubliez pas d'envoyer les données audio à la moitié du temps réel (15 secondes d'audio) par créneau de 30 secondes. Cette fréquence est en général suffisante pour tenir compte des temps d'attente de réseau et des retards.