IBM Cloud Docs
音声の送信とタイムアウト

音声の送信とタイムアウト

IBM Watson® Speech to Text サービスを使用すると、音声を一度にサービスに渡したり、音声をサービスにストリーミングしたりできます。 音声ストリーミングの場合、進行中のセッション・アクティビティーを確保するために、サービスはタイムアウトを強制します。

音声の伝送

WebSocket インターフェースの場合、音声データは常に、接続を介してサービスにストリーミングされます。 ソケットを使用して一度にすべてのデータを渡すか、ライブ使用の場合は使用可能になったデータを順次渡すことができます。 サービスからは、使用可能になった順に結果が返されます。

HTTP インターフェースの場合、以下の方法のいずれかで音声をサービスに伝送できます。

  • 1 回限りの配信。 Transfer-Encoding 要求ヘッダーを省略し、すべての音声データを一度に 1 回の配信としてサービスに渡します。
  • ストリーミング。 Transfer-Encoding 要求ヘッダーを値 chunked に設定して、持続接続を介してデータをストリーミングします。 サービスへのデータのストリーミングを開始する前に、データが完全に揃っている必要はありません。 使用可能になった順にデータをストリーミングできます。 サービスは、最終チャンクを受信した、つまり、最終を示す空のチャンクが送信されてきた場合にのみ、結果を送信します。

For more information, see トランスファーコーディング in IETF RFC 7320 'HTTP/1.1:メッセージ構文とルーティング

HTTP インターフェースの場合、サービスでは常に、結果の送信前に音声ストリーム全体が書き起こされます。 結果には、休止で区切られた句を示す複数の transcript 要素が含まれることがあります。 transcript 要素を連結して、完全な書き起こしを組み立ててください。

サービスでは、ストリーミング・セッションのタイムアウトが適用されます。 長時間の無音を検出した場合、または 30 秒間音声を受信しなかった場合、ストリーミング・セッションが終了されることがあります。 タイムアウトおよびその回避方法について詳しくは、タイムアウトを参照してください。

音声の伝送の例

以下の要求例では、chunked ヘッダーに Transfer-Encoding が指定されており、ストリーミング・モードが使用されます。 接続はオープンのままで、音声の追加チャンクが受け入れられます。

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"

タイムアウト

HTTP 音声認識メソッドまたは WebSocket 音声認識メソッドでストリーミング・セッションを開始すると、サービスでは、非アクティブ・タイムアウトおよびセッション・タイムアウトが適用されます。 ストリーミング・セッション中にタイムアウトが経過した場合、サービスによって接続がクローズされます。 クローズされたと考えられる接続は、アプリケーションで正常に回復する必要があります。

HTTP を介して音声をストリーミングしている場合、20 秒ごとにサービスから応答でスペース文字が送信されます。 サービスでこれを行うことにより、30 秒の HTTP REST 非アクティブ・タイムアウトが回避されてユーザビリティーが向上します。 認識が進行している間中接続を保持するために、サービスでは、書き起こしが完了するまでこのスペース文字の送信が続けられます。 スペース文字は、JSON エンコードされた応答データには影響しません。

この HTTP 非アクティブ・タイムアウトは、サービスの非アクティブ・タイムアウトとは異なります。 WebSocket インターフェースでは、この HTTP タイムアウトは適用されません。

非アクティブ・タイムアウト

非アクティブ・タイムアウト (HTTP ステータス・コード 400) が発生するのは、サービスで音声を受信しているが、連続した無音または非音声アクティビティー (発話なし) が 30 秒間検出された場合です。 サービスはエラー・メッセージ No speech detected for 30s を送信します。 この非アクティブ・タイムアウトは、例えばユーザーが単にライブ・マイクから離れた場合にセッションを終了する際に役立ちます。

デフォルトの非アクティブ・タイムアウトは 30 秒です。 この値は、inactivity_timeout パラメーターを使用して指定変更できます。 非アクティブ・タイムアウトを増加するには、より大きな値を指定します。 非アクティブ・タイムアウトを無期限に設定するには、値 -1 を指定します。 サービスに送信する音声は、無音も含めてすべて課金されるので、非アクティブ・タイムアウトを増加すると、無音のみを送信するストリーミング・セッションのために追加料金がかかる場合があります。

非アクティブ・タイムアウトの例

以下の要求例では、非アクティブ・タイムアウトを 60 秒に設定しています。 要求では、初期ファイルが送信されて、ストリーミング・セッションが開始されます。

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"

セッションのタイムアウト

セッション・タイムアウト (HTTP ステータス・コード 408) が発生するのは、ストリーミング・セッションをアクティブに保つのに十分な音声を送信できなかった場合です。 以下の理由により、サービスでは、セッションがアイドル状態であると見なされ、セッション・タイムアウトがトリガーされる場合があります。

  • 30 秒間のうち 15 秒以上の音声をサービスに送信できなかった。

    最終チャンクを送信してストリームの終了を示すまでは、30 秒間のうち 15 秒以上音声を送信する必要があります。 inactivity_timeout パラメーターがより大きい値または -1 に設定されている場合は、音声は無音でもかまいません。 サービスに送信するすべての音声の所要時間には、無音も含めて課金されます。

  • リアルタイムよりも遅い速度で音声をストリーミングした。

    理想としては、書き起こす音声を取得する直前にセッションを確立する要求を開始します。 その後、リアルタイムに近い速度で音声を送信して、セッションを維持します。

最終チャンクを送信してストリームの終了を示した後は、セッション・タイムアウトを気にする必要はありません。 サービスは、書き起こしの最終結果を返すまで、音声の処理を継続します。

長い音声ストリームの書き起こし時に、サービスで音声を処理して応答を生成するのに 30 秒を超える時間がかかることがあります。 サービスでは、受信したすべての音声の処理を終了するまでは、セッション・タイムアウトを計算し始めません。 サービスの処理時間が原因となって、セッションで 30 秒のセッション・タイムアウトを超えることはありません。

例えば、セッションの最初の 10 秒に 1 時間の音声を送信した場合、サービスが音声を処理するのに 300 秒かかるとします。 このセッションを保持するには、340 秒以内にセッションに無音を含む何らかの音声を 15 秒以上送信する必要があります。

この例で、セッションの 100 秒のマークで別の 15 秒の音声を送信した場合、サービスがこの音声を処理するのに追加で 2 秒かかるとします。 この場合、342 秒以内にセッションに音声を 15 秒以上送信する必要があります。

ストリーミング・セッションがアイドル状態かどうかを判別するために、処理時間に依存したり、結果を受信したかどうかに依存したりしないでください。 サービスではすべての音声が即時に処理されると想定して、それに応じてサービスにデータを送信してください。 リアルタイムで音声をストリーミングする場合、音声の送信が 30 秒間のうちリアルタイムの半分 (15 秒の音声) より遅れないようにしてください。 通常、ネットワーク待ち時間や遅延に適応するには、この速度で十分です。