オーディオ待ち時間の短縮の欠点

オーディオ待ち時間の短縮の欠点

オーディオサーバー(私の場合はパイプライン)を使用すると、「遅延」を変更できることがわかりました。 (申し訳ありませんが、私はこれらのことについて知ることはあまりありません。)

PIPEWIRE_LATENCY="128/48000"

Arch Linux Wikiでは、これを「カスタムバッファサイズの要求」として説明しています。

待ち時間を非常に低く設定するのに「欠点」があるかどうか疑問に思います。反応性に優れたオーディオは、単にリソースコストが高いという意味ですか?

ベストアンサー1

バッファが小さいほど、より早く満たされ、より速く空になります。これが遅延時間が短縮される理由です。

ただし、データをバッファに入れてバッファからデータを取得するプロセスは、より頻繁にトリガされます。したがって、バッファを小さすぎると、オーディオソフトウェアがコンピュータのCPUを消費する可能性があります。極端な場合、バッファが小さいオーディオシステムを使用すると、コンピュータの他のソフトウェアがより遅く反応する可能性があります。あるいは、滑らかさとストップを交互に「トリム」または「トリム」が発生する可能性があります。

小さなバッファは、オーディオデータをバッファに入れるプロセスが十分に速く応答できず、短い時間内にバッファが完全に空になると、オーディオストリームで途切れることがあります。バッファからオーディオデータを取り出し、出力を介してスピーカー(またはヘッドフォン)に転送すると、データが使い果たされ、サウンドが中断(しばしば「ドロップアウト」と呼ばれる)を経験します。

どのサイズが「小さすぎるか」を予測するのは難しいため、オーディオストリームやコンピュータの他の部分に影響を与えることなく、最短の待ち時間を提供する妥協案を試す必要があるかもしれません。

おすすめ記事