Transmisión y tiempos de espera de audio

El servicio IBM Watson® Speech to Text le permite pasar el audio al servicio todo a la vez o transmitir audio al servicio. Para la transmisión de audio, el servicio aplica tiempos de espera para garantizar la actividad de sesión en curso.

Transmisión de audio

Con la interfaz WebSocket, los datos de audio siempre se envían en secuencia al servicio a través de la conexión. Puede pasar todos los datos a la vez a través del socket o puede pasar datos en directo a medida que estén disponibles. El servicio devuelve resultados a medida que están disponibles.

Con las interfaces HTTP, puede transmitir el audio al servicio de una de las formas siguientes:

  • Entrega única. Omite la cabecera de solicitud de Transfer-Encoding y pasa todos los datos de audio al servicio al mismo tiempo como una sola entrega.
  • Secuencia. Se define para la cabecera de solicitud Transfer-Encoding el valor chunked y los datos se transmiten en secuencia sobre una conexión permanente. No es necesario que existan todos los datos antes de transmitirlos en secuencia al servicio. Puede enviar en secuencia los datos a medida que están disponibles. El servicio solo envía resultados cuando recibe el bloque de datos final, que se indica mediante el envío de un bloque de datos vacío.

Para más información, consulte Transfer Codings en IETF RFC 7320 HTTP/1.1: Sintaxis y enrutamiento de mensajes

Con las interfaces HTTP, el servicio siempre transcribe toda la secuencia de audio antes de enviar resultados. Los resultados pueden incluir varios elementos transcript para indicar frases que están separadas por pausas. Concatenen los elementos transcript para ensamblar la transcripción completa.

El servicio aplica tiempos de espera excedidos en una sesión de secuencia de audio. Puede finalizar una sesión de secuencia de audio si detecta un período de silencio prolongado o si no recibe ningún audio durante un período de 30 segundos. Para obtener información sobre tiempos de espera excedidos y cómo evitarlos, consulte Tiempos de espera excedidos.

Ejemplo de transmisión de audio

La solicitud de ejemplo siguiente especifica chunked para la cabecera Transfer-Encoding para utilizar la modalidad de secuencia. La conexión permanece abierta para aceptar segmentos de audio adicionales.

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"

Tiempos de espera excedidos

Cuando se inicia una sesión de secuencia de audio con los métodos de reconocimiento de voz HTTP o WebSocket, el servicio aplica tiempos de espera excedidos de inactividad y de sesión. Si se produce un tiempo de espera excedido durante una sesión de secuencia de audio, el servicio cierra la conexión. La aplicación se debe recuperarse de las posibles conexiones cerradas.

Cuando se transmiten secuencias de audio a través de HTTP, el servicio envía un carácter de espacio en su respuesta cada 20 segundos. Lo hace para facilitar el uso al evitar el tiempo de espera excedido de inactividad de REST HTTP de 30 segundos. Para mantener la conexión activa mientras el reconocimiento está en curso, el servicio continúa enviando este carácter de espacio hasta que completa la transcripción. El carácter de espacio no tiene ningún efecto en los datos de respuesta codificados en JSON.

Este tiempo de espera excedido de inactividad de HTTP es distinto del tiempo de espera excedido de inactividad del servicio. La interfaz WebSocket no está sujeta a este tiempo de espera excedido de HTTP.

Tiempo de espera de inactividad

Se produce un tiempo de espera excedido de inactividad (código de estado 400 de HTTP) cuando el servicio recibe el audio, pero solo detecta silencio continuo o actividad sin voz (sin habla) durante 30 segundos. El servicio envía el mensaje de error No speech detected for 30s. El tiempo de espera excedido de inactividad resulta útil, por ejemplo, para finalizar una sesión cuando un usuario simplemente se aleja de un micrófono activo.

El tiempo de espera excedido de inactividad predeterminado es 30 segundos. Puede alterar temporalmente este valor con el parámetro inactivity_timeout. Especifique un valor mayor para aumentar el tiempo de espera excedido de inactividad. Especifique el valor -1 para establecer el tiempo de espera excedido de inactividad en infinito. Se le factura todo el audio que envía al servicio, incluido silencio, por lo que aumentar el tiempo de espera excedido de inactividad puede ocasionar un gasto adicional para una sesión de secuencia de audio que solo envíe silencio.

Ejemplo de tiempo de espera de inactividad

La solicitud de ejemplo siguiente establece el tiempo de espera excedido de inactividad en 60 segundos. La solicitud envía un archivo inicial para empezar la sesión de secuencia de audio.

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"

Tiempo de espera de sesión

Se produce un tiempo de espera excedido de sesión (código de estado 408 de HTTP) cuando no se envía suficiente audio para mantener activa una sesión de secuencia de audio. El servicio puede considerar que una sesión está desocupada y activar un tiempo de espera excedido de sesión por los motivos siguientes:

  • No se ha podido enviar al menos 15 segundos de audio al servicio en una ventana de 30 segundos.

    Hasta que envíe el último fragmento para indicar el final de la secuencia, debe enviar al menos 15 segundos de audio dentro de cada periodo de 30 segundos. El audio puede estar en silencio si establece el parámetro inactivity_timeout en un valor mayor o en -1. Se le factura por la duración del audio que envía al servicio, incluido silencio.

  • Envía una secuencia de audio a una velocidad mucho más lenta que si fuera en tiempo real.

    Lo ideal es que inicie una solicitud para establecer una sesión justo antes de obtener el audio para la transcripción. En ese caso, mantendría la sesión enviando audio a una velocidad cercana a la de tiempo real.

No debe preocuparse por el tiempo de espera excedido de sesión después de enviar el último fragmento para indicar el final de la secuencia. El servicio continúa procesando el audio hasta que devuelve los resultados finales de la transcripción.

Cuando se transcribe una secuencia de audio larga, el servicio puede tardar más de 30 segundos en procesar el audio y generar la respuesta. El servicio no empieza a calcular el tiempo de espera de la sesión hasta que finaliza el proceso de todo el audio que ha recibido. El tiempo de proceso del servicio no puede hacer que la sesión supere el tiempo de espera excedido de la sesión de 30 segundos.

Por ejemplo, si envía una hora de audio durante los 10 primeros segundos de una sesión, el servicio puede tardar 300 segundos en procesar el audio. Para mantener viva esta sesión, tendría que enviar al menos 15 segundos más de audio, incluido silencio, no más tarde de 340 segundos a la sesión.

En este ejemplo, si fuera a enviar otros 15 segundos de audio a una marca de la sesión de 100 segundos, el servicio podría tardar otros dos segundos en procesar este audio. En este caso, tendría que enviar 15 segundos más de audio no más tarde de 342 segundos a la sesión.

No se base en el tiempo de proceso o en si se han recibido resultados para determinar si una sesión de secuencia de audio está desocupada. Suponga que el servicio puede procesar todo el audio de forma instantánea y envíe los datos al servicio en consecuencia. Si envía secuencias de audio en tiempo real, no se quede atrás enviando audio a la mitad del tiempo real (15 segundos de audio) en una ventana de 30 segundos. Esta velocidad suele ser suficiente para acomodar la latencia de red y los retardos.