Beispiel für die Übertragung von Audiodaten

In der folgenden Beispielanforderung ist der Wert chunked für den Header Transfer-Encoding angegeben, damit der Streaming-Modus verwendet wird. Die Verbindung bleibt geöffnet, damit weitere Audiodatenblöcke akzeptiert werden können.

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"

Inaktivitätszeitlimit

Das Inaktivitätszeitlimit (HTTP-Statuscode 400) tritt ein, wenn der Service Audiodaten empfängt, 30 Sekunden lang jedoch lediglich fortdauerndes Schweigen oder aber keine Sprachgeräusche empfängt. Der Service sendet in diesem Fall die Fehlernachricht No speech detected for 30s. Das Inaktivitätszeitlimit ist beispielsweise von Nutzen, um eine Sitzung zu beenden, wenn sich ein Benutzer einfach von einem eingeschalteten Mikrofon entfernt.

Der Standardwert für das Inaktivitätszeitlimit beträgt 30 Sekunden. Diesen Wert können Sie mit dem Parameter inactivity_timeout außer Kraft setzen. Geben Sie einen größeren Wert an, um das Inaktivitätszeitlimit zu erhöhen. Geben Sie den Wert -1 an, um ein unendliches Inaktivitätszeitlimit zu definieren. Alle Audiodaten, die Sie an den Service senden, werden Ihnen in Rechnung gestellt, was auch Schweigen umfasst. Ein Heraufsetzen des Inaktivitätszeitlimits kann daher zusätzliche Gebühren für eine Streamingsitzung verursachen, über die lediglich Schweigen übertragen wird.

Beispiel für Inaktivitätszeitlimit

Mit der folgenden Beispielanforderung wird das Inaktivitätszeitlimit auf 60 Sekunden gesetzt. Die Anforderung sendet eine Anfangsdatei, um die Streamingsitzung zu starten.

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"

Sitzungszeitlimit

Ein Sitzungszeitlimit (HTTP-Statuscode 408) tritt ein, wenn die von Ihnen gesendeten Audiodaten nicht ausreichen, um eine Streamingsitzung im aktiven Zustand zu halten. Der Service kann aus den folgenden Gründen eine Sitzung für inaktiv halten und ein Sitzungszeitlimit auslösen:

• In jedem Zeitfenster von 30 Sekunden werden nicht mindestens 15 Sekunden lange Audiodaten an den Service gesendet.

  Bis Sie den letzten Block senden, um das Ende des Datenstroms kenntlich zu machen, müssen Sie in jedem 30 Sekunden langen Zeitraum mindestens 15 Sekunden lange Audiodaten senden. Bei den Audiodaten kann es sich um Schweigen handeln, falls Sie für den Parameter inactivity_timeout einen höheren Wert als -1 festgelegt haben. Die gesamte Dauer der Audiodaten, die Sie an den Service senden, wird Ihnen in Rechnung gestellt, was auch Schweigen umfasst.

• Das Streaming der Audiodaten erfolgt in einer Geschwindigkeit, die unter der Echtzeit liegt.

  Im Idealfall starten Sie eine Anforderung zum Aufbau einer Sitzung unmittelbar vor dem Erhalt von Audiodaten für die Transkription. Anschließend erhalten Sie die Sitzung aufrecht, indem Sie Audiodaten mit einer Geschwindigkeit senden, die nahezu Echtzeit entspricht.

Nachdem Sie den letzten Block gesendet haben, um das Ende der Sitzung anzugeben, müssen Sie sich keine Gedanken um das Sitzungszeitlimit machen. Der Service setzt die Verarbeitung der Audiodaten fort, bis er die Endergebnisse für die Transkription zurückgibt.

Wenn Sie einen langen Audiodatenstrom transkribieren, kann der Service mehr als 30 Sekunden benötigen, um die Audiodaten zu verarbeiten und eine Antwort zu generieren. Der Service beginnt erst dann mit der Berechnung des Sitzungszeitlimits, wenn er die Verarbeitung aller empfangenen Audiodaten abgeschlossen hat. Die vom Service zur Verarbeitung benötigte Zeit kann in keinem Fall ein Überschreiten des Sitzungszeitlimits von 30 Sekunden verursachen.

Beispiel: Falls Sie in den ersten 10 Sekunden einer Sitzung Audiodaten mit einer Dauer von einer Stunde senden, benötigt der Service möglicherweise 300 Sekunden, um die Audiodaten zu verarbeiten. Damit diese Sitzung aufrecht erhalten bleibt, müssen Sie spätestens nach 340 Sekunden mindestens 15 Sekunden Audiodaten an die Sitzung senden.

Wenn Sie bei diesem Beispiel nach 100 Sekunden Sitzungsdauer weitere 15 Sekunden Audiodaten an die Sitzung senden, benötigt der Service zur Verarbeitung dieser Audiodaten möglicherweise weitere zwei Sekunden. In diesem Fall müssten Sie spätestens nach 342 Sekunden weitere 15 Sekunden Audiodaten an die Sitzung senden.

Verlassen Sie sich bei der Ermittlung, ob eine Streamingsitzung inaktiv ist, nicht auf die Verarbeitungszeit oder darauf, dass Sie Ergebnisse empfangen haben. Gehen Sie davon aus, dass der Service alle Audiodaten sofort verarbeiten kann, und senden Sie dementsprechend Daten an den Service. Bleiben Sie beim Streaming von Audiodaten in Echtzeit in jedem Zeitfenster von 30 Sekunden mit dem Senden von Audiodaten nicht hinter der Hälfte der Echtzeit (15 Sekunden Audiodaten) zurück. Diese Geschwindigkeit reicht normalerweise aus, um Netzlatenz und Verzögerungen zu kompensieren.