音频传输和超时

IBM Watson® Speech to Text服务可让您一次性将音频传输到服务，或将音频流传输到服务。对于音频流，服务会强制执行超时，以确保会话活动持续进行。

音频传输

使用 WebSocket 接口时，音频数据始终会通过连接流式传输到服务。您可以通过套接字一次性传递全部数据，也可以针对实时用例在数据可用时传递数据。服务将在结果可用时返回结果。

使用 HTTP 接口时，可以通过下列任一方式将音频传输到服务：

一次投递。 您可以省略 "Transfer-Encoding 请求标头，将所有音频数据作为单个传输数据一次性传递给服务。
流媒体。 将 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

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 超时的影响。

不活动状态超时

服务正在接收音频，但在 30 秒内仅检测到持续静默或非语音活动（无语音），那么会发生不活动状态超时（HTTP 状态码 400）。服务将发送错误消息：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

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 秒内发送了一小时的音频，服务处理该音频可能需要 300 秒。为了使此会话保持活动状态，需要在会话的前 340 秒内再发送至少 15 秒的一些音频，包括静默。

在此示例中，如果在会话的 100 秒标记处发送了另一个 15 秒音频，那么服务可能需要额外 2 秒时间来处理此音频。在这种情况下，您需要在会话的前 342 秒内再发送 15 秒的音频。

不要依赖于处理时间或是否收到结果来确定流式会话是否空闲。假定服务可以立即处理所有音频，并相应地将数据发送到服务。如果是实时流式传输音频，对于任何 30 秒时段，发送音频的速率不要慢于实时速率的一半（15 秒音频）。此速率通常足以满足网络等待时间和延迟的需求。