Trasmissione audio e timeout

Il servizio IBM Watson® Speech to Text consente di passare l'audio al servizio tutto in una volta o di trasmettere l'audio al servizio. Per lo streaming audio, il servizio impone dei timeout per garantire l'attività continua della sessione.

Trasmissione audio

Con l'interfaccia WebSocket, i dati audio vengono sempre inviati in streaming al servizio sulla connessione. Puoi passare i dati attraverso il socket tutti insieme oppure puoi passare i dati per il caso di utilizzo dal vivo man mano che diventano disponibili. Il servizio restituisce i risultati man mano che diventano disponibili.

Con le interfacce HTTP, puoi trasmettere l'audio al servizio in uno dei due modi di seguito indicati:

  • Fornitura unica. Si omette l'intestazione della richiesta di trasmissione ( Transfer-Encoding ) e si trasmettono tutti i dati audio al servizio in una sola volta come consegna singola.
  • Streaming. Imposti l'intestazione della richiesta Transfer-Encoding sul valore chunked e invii in streaming i dati su una connessione persistente. I dati non devono esistere completamente prima che tu ne esegua lo streaming al servizio. Puoi inviare in streaming i dati man mano che diventano disponibili. Il servizio invia i risultati solo quando riceve la porzione finale, che indichi inviando una porzione vuota.

Per ulteriori informazioni, vedere Codifiche di trasferimento in IETF RFC 7320 HTTP/1.1: Sintassi del messaggio e instradamento

Con le interfacce HTTP, il servizio trascrive sempre l'intero flusso audio prima di inviare eventuali risultati. I risultati possono includere più elementi transcript per indicare le frasi separate da pause. Concatena gli elementi transcript per assemblare la trascrizione completa.

Il servizio applica i timeout su una sessione di streaming. Può terminare una sessione di streaming se rileva un lungo periodo di silenzio o non riceve audio durante un periodo di 30 secondi. Per ulteriori informazioni sui timeout e su come evitarli, vedi Timeout.

Esempio di trasmissione audio

La seguente richiesta di esempio specifica chunked per l'intestazione Transfer-Encoding per utilizzare la modalità di streaming. La connessione rimane aperta per accettare ulteriori porzioni di 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"

Timeout

Quando avvii una sessione di streaming con i metodi di riconoscimento vocale HTTP o WebSocket, il servizio applica i timeout di inattività e sessione. Se un timeout scade durante una sessione di streaming, il servizio chiude la connessione. La tua applicazione deve risolvere normalmente le possibili connessioni chiuse.

Quando invii in streaming l'audio su HTTP, il servizio invia un carattere di spazio nella sua risposta ogni 20 secondi. Il servizio esegue tale operazione per migliorare l'utilizzabilità evitando il timeout di inattività REST HTTP di 30 secondi. Per mantenere attiva la connessione mentre è in corso il riconoscimento, il servizio continua a inviare questo carattere di spazio finché non completa la sua trascrizione. Il carattere di spazio non ha alcun effetto sui dati di risposta con codifica JSON.

Il timeout di inattività HTTP è diverso dal timeout di inattività del servizio. L'interfaccia WebSocket non è soggetta a questo timeout HTTP.

Timeout di inattività

Un timeout di inattività (codice di stato HTTP 400) si verifica quando il servizio sta ricevendo audio ma rileva solo silenzio continuo o attività non vocale (nessun discorso) per 30 secondi. Il servizio invia il messaggio di errore No speech detected for 30s. Il timeout di inattività è utile, ad esempio, per terminare una sessione quando un utente semplicemente si allontana da un microfono dal vivo.

Il timeout di inattività predefinito è 30 secondi. Puoi sovrascrivere questo valore utilizzando il parametro inactivity_timeout . Specifica un valore maggiore per aumentare il timeout di inattività. Specifica un valore di -1 per impostare il timeout di inattività su un tempo indefinito. Ti viene addebitato tutto l'audio che invii al servizio, compreso il silenzio, quindi aumentare il timeout di inattività può comportare degli addebiti aggiuntivi per una sessione di streaming che invia solo silenzio.

Esempio di timeout di inattività

La seguente richiesta di esempio imposta il timeout di inattività su 60 secondi. La richiesta invia un file iniziale per avviare la sessione di streaming.

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"

Timeout della sessione

Un timeout della sessione (codice di stato HTTP 408) si verifica quando non riesci a inviare una quantità di audio sufficiente a mantenere attiva una sessione di streaming. Il servizio può considerare inattiva una sessione e attivare un timeout della sessione per i seguenti motivi:

  • Non riesci a inviare almeno 15 secondi di audio al servizio in qualsiasi finestra di 30 secondi.

    Finché non invii l'ultima porzione per indicare la fine del flusso, devi inviare almeno 15 secondi di audio entro qualsiasi periodo di 30 secondi. L'audio può consistere in silenzio se imposti il parametro inactivity_timeout su un valore più grande o su -1. Ti viene addebitata la durata di qualsiasi audio che invii al servizio, compreso il silenzio.

  • Invii il flusso audio a una velocità molto più lenta di quella in tempo reale.

    Idealmente, inizi una richiesta di stabilire una sessione immediatamente prima di ottenere l'audio per la trascrizione. Mantieni quindi la sessione inviando l'audio a una velocità prossima a quella in tempo reale.

Non ti devi preoccupare del timeout della sessione dopo che hai inviato l'ultima porzione per indicare la fine del flusso. Il servizio continua a elaborare l'audio finché non restituisce i risultati finali della trascrizione.

Quando trascrivi un flusso audio lungo, il servizio può impiegare più di 30 secondi per elaborare l'audio e generare una risposta. Il servizio inizia a calcolare il timeout della sessione solo dopo che ha terminato l'elaborazione di tutto l'audio che ha ricevuto, Il tempo di elaborazione del servizio non può causare per la sessione il superamento del suo timeout di 30 secondi.

Ad esempio, se invii un'ora di audio nei primi 10 secondi di una sessione, il servizio può impiegare 300 secondi per elaborare l'audio. Per mantenere questa sessione attiva, devi inviare almeno altri 15 secondi di audio, compreso il silenzio, non più tardi di 340 secondi dall'inizio della sessione.

In questo esempio, se invii altri 15 secondi di audio al segno dei 100 secondi della sessione, il servizio può dedicare due secondi in più all'elaborazione di questo audio. In questo caso, devi inviare altri 15 secondi di audio non più tardi di 342 secondi dall'inizio della sessione.

Non fare affidamento sul tempo di elaborazione o sull'avere eventualmente ricevuto risultati per determinare se una sessione di streaming è inattiva. Supponi che il servizio possa elaborare tutto l'audio istantaneamente e invia i dati al servizio di conseguenza. Se invii in streaming l'audio in tempo reale, non restare indietro con l'invio di audio a metà del tempo reale (15 secondi di audio) in qualsiasi finestra di 30 secondi. Questa frequenza è di norma sufficiente per tenere conto dei ritardi e della latenza di rete.