Web Audio Api實時流式傳輸PCM ADPCM

Question

我有一台服務器傳遞客戶端PCM或ADPCM數據。

我最初決定使用PCM，因為我不想處理編碼和解碼。

我得到PCM工作但是在每一段音頻之間我都聽到了毛刺。（有點像剪輯）

所以我想也許原因是延遲/高質量的音頻和所有這些東西。

所以我決定使用ADPCM來減少數據量。 我在javascript中寫了一個adpcm到pcm解碼器。 這很麻煩。 我希望，因為數據計數減少可能會阻止故障（數據將趕上正在播放的內容）

但是我錯了。 我仍然有毛刺。

這甚至可以用TCP完成嗎？ 或者這是一個失敗的原因。 我沒有UDP over websockets。

我需要實現緩沖算法嗎？ 我不想這樣做，因為它是實時音頻，我只是想盡快處理它。

你們知道一個很好的鏈接，通過網絡閱讀有關實時音頻的信息。

我可以給出代碼示例，但這是一個高級問題。

PS：我試圖使用制表符，但我們遇到緩沖問題，我們無法控制它。 我也沒有從服務器獲得任何流量控制。 它沒有說音頻啟動器或音頻停止了我們的暫停。 它是推送協議，我得到的只是ADPCM和PCM數據

Answer 1

是的，當然你可以使用TCP。 UDP通常用於電話應用程序，因為較低的開銷使一切更快，對於此應用程序，數據包是否被丟棄或以錯誤的順序到達並不重要。 但由於UDP不是一個選項，您可以使用TCP。

正如您所懷疑的那樣，在我看來，您的問題是緩沖區不足。 您與服務器的連接速度不夠快（或者至少足夠快），或者您沒有以足夠快的速度從編碼器提供數據。 如果您實時記錄數據並嘗試實時播放，則可能會發生這種情況。

解決方案是在將數據發送到客戶端之前緩沖數據服務器端。 擁有與延遲要求允許的一樣大的緩沖區。 對於互聯網廣播目的，我通常會選擇一個30秒的緩沖區，因為延遲並不重要。 出於您的目的，您可能需要至少64KB的緩沖區。 這是TCP數據包中允許的最大大小。 這個包將在整個過程中碎片化，但這沒關系。

您還可以查看服務器如何發送數據。 嘗試禁用Nagle算法，以便服務器在發送更多數據之前不等待ACK。