一方向ストリーミングオーディオデバイスにはどのような種類のバッファを実装する必要がありますか？

オーディオデータがデバイスにストリーミングされるプロジェクトに取り組んでいます。オーディオデータはオーパス経由でエンコードされ、一度に20 msのペイロードでストリーミングされます。パケット損失を完全に回避するために、ストリーミングはTCP経由で行われます。ストリーミングの目的は、オーディオの損失やジッターを発生させずに、ライブオーディオストリーミングにできる限り近づけることです。

現在、遅いインターネット接続で何が起こるか、オーディオが少しジッターすることがあります。私は現在バッファを使用していませんが、目標はできるだけ「ライブストリーミング」に近づけることができると同時にジッターを排除することです。

私はジッターバッファーを調べましたが、ジッターバッファーも両端で遅延を処理して、両端が可能な限り同期するようになっているようです。静的なバッファサイズを作成した場合、必要がなければ、ライブストリーミングの側面からそれを取り除くことになると思います。

だから、これはいくつかの質問を私に残します、それらはすべて何らかの形で関連しています。

1. バッファー長を検出するための適切な方法またはアルゴリズムは何ですか？
2. 受信側のデコーダーにデータを送り始めるための最良の方法は何ですか？バッファが一定のミリ秒に達すると、20ミリ秒のペイロードでデータの供給を開始しますか？
3. バッファーがいっぱいになった場合、再生を遅らせますか？
4. バッファはバイトまたは時間の長さになりますか？

本当にありがとう！

それは、ネットワークのスループットに完全に依存します。1秒のデータを満たしておくことができれば、それで十分です。明らかに、ネットワークがどんどん詰まってバッファーが満たされなくなるまでの時間を決定する必要があります。それをテストして見てください。

それ以外の場合は、バッファサイズを設定する方が簡単かもしれません。高速ネットワークでは1秒のバッファがあり（オーディオがキャプチャの1秒遅れていることに気付かないでしょう）、遅延が大きく遅いネットワークやスループットの低いネットワークでは、さらにバッファリングする可能性があります。バッファが完全に空になると、再生中にバッファのサイズを変更できる可能性がありますが、この場合、再生が途切れ途切れにならない可能性が高くなります。

一般的に、バッファが完全に空になった場合にのみ、再生を遅らせます。バッファを使用しない場合は、バッファを用意しても意味がありません。

オーディオが20msパケットの場合、サイズ==時間。