オーディオサーバー（私の場合はパイプライン）を使用すると、「遅延」を変更できることがわかりました。 （申し訳ありませんが、私はこれらのことについて知ることはあまりありません。）
PIPEWIRE_LATENCY="128/48000"
Arch Linux Wikiでは、これを「カスタムバッファサイズの要求」として説明しています。
待ち時間を非常に低く設定するのに「欠点」があるかどうか疑問に思います。反応性に優れたオーディオは、単にリソースコストが高いという意味ですか？
答え1
バッファが小さいほど、より早く満たされ、より速く空になります。これが遅延時間が短縮される理由です。
ただし、データをバッファに入れてバッファからデータを取得するプロセスは、より頻繁にトリガされます。したがって、バッファを小さすぎると、オーディオソフトウェアがコンピュータのCPUを消費する可能性があります。極端な場合、バッファが小さいオーディオシステムを使用すると、コンピュータの他のソフトウェアがより遅く反応する可能性があります。あるいは、滑らかさとストップを交互に「トリム」または「トリム」が発生する可能性があります。
小さなバッファは、オーディオデータをバッファに入れるプロセスが十分に速く応答できず、短い時間内にバッファが完全に空になると、オーディオストリームで途切れることがあります。バッファからオーディオデータを取り出し、出力を介してスピーカー（またはヘッドフォン）に転送すると、データが使い果たされ、サウンドが中断（しばしば「ドロップアウト」と呼ばれる）を経験します。
どのサイズが「小さすぎるか」を予測するのは難しいため、オーディオストリームやコンピュータの他の部分に影響を与えることなく、最短の待ち時間を提供する妥協案を試す必要があるかもしれません。
答え2
サウンドアプリケーション（A）、サウンドサーバー（B）、alsaサウンドカードドライバ（C）に関係なく：
- （A）サンプルを（自己速度PAで）いくつかのバッファに書き込みます。
- （B）一部のバッファに（対応する速度で）書き込むために（対応する速度で）読み込みます。
- サウンドカードの割り込みハンドラは、ハードウェアサウンドカードの通常の固定サイズの非常に小さなバッファを読み込みます（PCの一定速度で）。
- 組み込みソフトウェアはこのデータを読み取り、非常に正確な速度でハードウェア出力に反映します。
これらの作業方法により、次のことを理解できます。
- （すぐに）方法はありません」遅延設定"。（（A）サンプルを出力する時点からそのサンプルを出力するハードウェアまでかかる時間として理解できます。「待ち時間を非常に低く設定する欠点」
- プロセスに関連するさまざまなコンポーネントが非同期で動作するため、バッファが必要になるため、バッファのサイズは、いくつかの（？）時々、いくつかのアップストリームコンポーネントが直後のコンポーネントよりも多く（またはより少ない）サンプルを出力することを考慮する必要があります。 。 。
前の段落では、バッファの観点から次のことがわかります。
バッファサイズが小さすぎるとリングバッファの可能性が高くなります。オーバーフローが発生する可能性があります。
つまり、サンプルはハードウェア出力に渡されず、これは可聴音に変換されます。
そうですね！バッファサイズを小さくすると、次のような欠点があります。過剰支出。
もちろん、限度超過リスクを減らす方法もあります。プロセスを適切な速度で実行してください。
ダウンストリームコンポーネントがタイムリーに（アップストリームコンポーネントよりも速いまたは同じ速度で）操作を完了できるようにすることができる場合は、バッファサイズに関係なくオーバーフローのリスクを回避できます。
- まず、irqがスレッド化され、サウンドカードに関連するカーネルスレッドのリアルタイム優先順位が最大であることを確認してください。
- 以下は、上記のirqカーネルスレッドの優先順位よりも低い優先順位を持ついくつかのリアルタイムスケジューリングモデルで実行されるサウンドサーバーである必要があります。
- 最終的に、アップストリームアプリケーションもリアルタイム予約モデルに従って実行され、サウンドサーバーよりも優先順位が低くなります。
また、2つのバッファを備えたサウンドサーバーは高価であり（追加の待ち時間の面で）...何も役に立たず、...削除を検討すると（正確に）考えることができます。