Modifier la langue de reconnaissance
Redémarrez les serveurs avec le module linguistique correspondant à la langue de votre choix.
Journaux
Le binaire Speech-to-Text possède quatre modes de journalisation :
debug
: journaux détaillés qui peuvent être utiles pour déboguer le binaire. Par exemple, les réponses du serveur sont consignées dans ce mode.prod
: paramètre recommandé pour la production. Les journaux contiennent des informations sur la version/le build du binaire, l'ouverture et la fermeture des sessions, les avertissements et les erreurs.warning
: les journaux ne contiennent que les avertissements ou les erreurs.error
: les journaux ne contiennent que les erreurs.
L'option --min_log_level
permet de contrôler la journalisation. Tous les journaux sont écrits dans stdout
.
Si vous rencontrez des problèmes, exécutez le serveur Speech-to-Text avec l'option de journal de débogage :
./speech_to_text_server --host_ip=${STT_IP?} --port=${STT_PORT?}\
--language_pack=${LANGUAGE_PACK?} --min_log_level="debug" \
--api_key=${API_KEY?}
Au démarrage, le binaire consigne les éléments suivants :
build ID
est un identifiant qui associe le binaire à un build.Language Pack ID
est l'identifiant du module linguistique chargé par le serveur.
Lors de la transcription, le serveur consigne l'identifiant request ID
fourni par le client. À la fin d'une session, le serveur consigne un état de session.
La journalisation devrait suffire pour résoudre les problèmes liés à une utilisation incorrecte. Elle peut également vous aider à comprendre le comportement du serveur. Par exemple, le serveur n'envoie aucune réponse à moins de reconnaître quelque chose dans l'audio. Si l'audio ne contient que du silence ou des sons non intelligible, aucune réponse ne sera envoyée.
État de la session
Une session réussie se termine avec l'état "OK".
... Closing StreamingRecognize ($request_id) with status OK
Une session ayant échoué se termine avec un état non OK, par exemple, si nous envoyons une nouvelle requête de configuration après la requête initiale.
... Closing StreamingRecognize ($request_id) with status INVALID_ARGUMENT: Malordered data received. Expected audio but received config. Send exactly one config, followed by audio data.
Enregistrements
Le serveur de reconnaissance vocale automatique accepte l'enregistrement de ses interactions pour faciliter le débogage de Google.
Exemple d'utilisation
Créez un répertoire pour stocker les enregistrements :
mkdir $PWD/recordings
Démarrez le serveur avec l'option --recordings
:
./speech_to_text_server --host_ip=${STT_IP?} --port=${STT_PORT?} \
--language_pack=${LANGUAGE_PACK?} --min_log_level="debug" \
--recordings=$PWD/recordings --api_key=${API_KEY?}
Démarrez le client avec la commande suivante :
./speech_to_text_client --server_ip=${STT_IP?} --port=${STT_PORT?} \
--audio=samples/*.wav
Cela devrait produire des fichiers au format suivant :
$PWD/recordings/{filename}_{timestamp}_requests.riegeli (1)
$PWD/recordings/{filename}_{timestamp}_responses.riegeli (2)
{filename} est le nom du fichier .wav
enregistré. Le speech_to_text_client
utilise filename
en tant que {request_id}. Le premier exemple ci-dessus est un fichier Riegeli contenant une séquence de StreamingRecognizeRequest
, le second est un fichier Riegeli contenant une séquence de StreamingRecognizeResponse
.
Format de fichier
Les enregistrements sont des fichiers riegeli contenant les requêtes et les réponses envoyées au serveur. La requête et les réponses sont écrites sur le disque dans l'ordre dans lequel elles sont envoyées vers et depuis le serveur.
Assistance supplémentaire
Pour résoudre les problèmes nécessitant une assistance, par exemple si des modifications du code sont nécessaires, veuillez fournir (le cas échéant) les éléments suivants :
- enregistrements
- journaux
- exemple de fichier audio
et une description du problème.