오디오 전송 및 제한시간

IBM Watson® Speech to Text 서비스를 사용하면 이 서비스에 오디오를 한 번에 모두 전달하거나 스트리밍하여 전달할 수 있습니다. 오디오 스트리밍의 경우 서비스는 제한시간을 강제하여 진행 중인 세션 활동을 보장합니다.

오디오 전송

WebSocket 인터페이스를 사용하면 오디오 데이터가 항상 연결을 통해 서비스로 스트리밍됩니다. 소켓을 통해 데이터를 동시에 전달하거나 라이브 유스 케이스에 대한 데이터의 경우 사용 가능하게 될 때 전달할 수 있습니다. 이 서비스는 사용 가능하게 될 때 결과를 리턴합니다.

HTTP 인터페이스를 사용하면 다음 두 가지 방법 중 하나로 오디오를 서비스에 전송할 수 있습니다.

  • 원샷(One-shot) 전달. Transfer-Encoding 요청 헤더를 생략하고 한 번에 모든 오디오 데이터를 단일 전달로서 서비스에 전달합니다.
  • 스트리밍. Transfer-Encoding 요청 헤더를 chunked 값으로 설정하고 지속적 연결을 통해 데이터를 스트리밍합니다. 데이터를 서비스에 스트리밍하기 전에 데이터가 완전히 존재하지 않아도 됩니다. 사용 가능하게 될 때 데이터를 스트리밍할 수 있습니다. 이 서비스는 비어 있는 청크를 전송하여 표시하는 최종 청크를 수신하는 경우에만 결과를 전송합니다.

자세한 내용은 ' 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초 창에서 1/2의 오디오(15초 길이의 오디오) 실시간으로 늦지 않게 전송하십시오. 이 속도는 일반적으로 네트워크 대기 시간을 지연을 수용하기에 충분합니다.