バッファ管理に関する限り、ライブオーディオストリーミングがどのように達成されるかを理解しようとしています。
オーディオの場合: 44100hz +/- クロック エラーでフレームをキャプチャするソースがあり、44100hz +/- クロック エラーでフレームを消費するオーディオ カード DAC を備えた受信機がある場合。
各端でのクロック エラーのため、受信側のバッファは (最終的に) 制御不能になるか、実行不足になります。
多くの受信者への 1 つのソース ライブ ストリーミングでは、フロー制御ストリームは使用できません。
私の唯一の解決策は、レシーバーでのバッファー フィルを (ネットワーク ジッターの影響よりも長い期間にわたって) 追跡し、サンプルを挿入するかサンプルを削除することです。
これに関する洞察は大歓迎です。ありがとう！
それは重要です。ネットワークを介した継続的で長期的なライブ オーディオのストリーミングは、冗談ではない業界でよく行われます。2 つの振動子が無視できるほど小さい偏差内にあると仮定するのは単純すぎます。
(余談ですが、状況によっては問題にならないと言っても問題ありません。たとえば、2 人の邪悪な大人が開いた墓に落ちるのを見たとき、パグスリー アダムスが姉のウェンズデー アダムスに質問したとします。彼は「彼らは死んでいますか?」と尋ねます。 ?」と彼女は素っ気なく答える、「それは問題ですか?」)
この問題に対処するための 3 つの可能なアプローチを次に示します。より多くの、またはより良い解決策を考えられる場合は、共有してください。レシーバーでサンプルレート変換を実行してエラーを修正します。 3) バッファーまたはキュー内のサンプル数を監視して、アンダーランまたはオーバーランが差し迫っている場合、オーディオ品質の深刻な低下を回避するために、いくつかのサンプルが生成またはドロップされるようにします。
受信機のクロックを制御できる場合は、最初の解決策が最適です。ALSA や PulseAudio のような高レベルのオーディオ ソフトウェア モジュールでそれを行う方法がわかりません (どんな提案もありがたく受け取りました!) サンプル レート変換を実行することは、哲学的には良いことかもしれませんが、その価値よりもはるかに CPU を集中的に使用することになります (さらに、不必要な失敗のリスク) したがって、私はバッファーの深さを監視し (5 月に提案されているように)、目立たないようにサンプルを出し入れすることに賛成です。
他にアイデアはありますか？
クロックが同期していないことは間違いありません。真実は、それは問題ではありません。
クロックが 5Hz もずれているとします (これは、通常よりも数倍大きい値です)。1 時間の間に、クロックは 0.4 秒しかずれません。これは、通常の 2 ～ 5 秒のバッファー時間よりも短い時間です。
ネットワークの問題は、多くの場合、クロック同期の問題よりもはるかに頻繁に再バッファリングを引き起こします。実際には、クロックの違いは通常 1Hz 以下であり、これはほとんど問題になりません。
再生を同期させたい場合、それはまったく別の問題です。幸いなことに、ストリーミング オーディオのリスナーは通常、これを行いません。