2017-08-31 79 views
0

我們正試圖通過JAVA客戶端使用Google StreamingRecognize方法。我們正在從麥克風讀取數據並將其發送到語音API。 使用以下設置: 識別配置 - LINEAR16,16KHz,en-US 我們嘗試將不同的緩衝區大小推送到StreamingRecognize(最多16000字節)。 我們觀察到獲得第一個結果需要至少4-5秒,並且在中間結果被流式傳輸之後。 任何人都可以確認這是否是API的預期行爲。也很高興知道爲什麼有這麼多的延遲。 是否有任何方法或解決方法來減少延遲。Google-Cloud-Speech:StreamingRecognize方法的第一個中間結果的延遲

請注意,後延遲我們得到的中間結果和最終的完整話語與合理的準確性

+0

我*懷疑*它正在等待獲得一些上下文才能產生第一個中期結果。 –

+0

任何關於上下文可能的猜測以及是否有可能最大限度地減少上下文造成的延遲。 Android SpeechRecognizer似乎工作正常。 –

+0

基本上,整個話語的語境。我不知道Android SpeechRecognizer是否使用了相同的技術* - 並且它可能會針對非常不同的場景進行優化(例如,對於許多句子,只需要幾個字)。我不確定自己是否還有我的C#流式語音應用程序 - 這是我使用它之後的一段時間。我記得開始的時候有一點延遲,但看起來並不大,我懷疑它是4-5秒。如果我有時間,我會盡力找到它並重現。 –

回答

0

我懷疑2層的行爲是錯誤的描述的情況下,

  1. 採樣率應不硬編碼或固定常量在您的Java服務應用程序中,因爲對於安裝在相應系統中的每個系統或麥克風適配器,採樣率會有所不同。即8000,16000,41000,4800等等,所以你需要從你的麥克風的音頻環境中選擇採樣率,並在第一次初始調用時發送它以在Requestconfig設置器中更新。

  2. 如果你是流通過在連接握手時的WebSocket發送這些採樣率,字節/幀到第一個要求觀察員和來自第二請求以後,你需要跳過第一個要求觀察員和可以直接傳遞到第二請求觀察員得到成績單。

如果以上幾點無效共享您的StreamingRecognize類。所以我可以相應地調整你的代碼