web-dev-qa-db-ja.com

ALSAにおけるピリオドの意味

私はLinuxでALSA forとオーディオアプリケーションを使用していますが、その使用方法を説明するすばらしいドキュメントが見つかりました： 1 および this one 。セットアップのこの部分を理解するためにいくつかの問題がありますが：

 /* Set number of periods. Periods used to be called fragments. */ 
if (snd_pcm_hw_params_set_periods(pcm_handle, hwparams, periods, 0) < 0) {
  fprintf(stderr, "Error setting periods.\n");
  return(-1);
}

再生モードを使用しているときに期間数を設定するとはどういう意味ですか？

/* Set buffer size (in frames). The resulting latency is given by */
/* latency = periodsize * periods / (rate * bytes_per_frame)     */
if (snd_pcm_hw_params_set_buffer_size(pcm_handle, hwparams, (periodsize * periods)>>2) < 0) {
  fprintf(stderr, "Error setting buffersize.\n");
  return(-1);
}

レイテンシに関するここでの同じ質問、どうすれば理解できますか？

clinuxaudioalsa
17
Engine

linux-journalのこのセクション を読んで理解していると思います。また、ALSAのコンテキストで、期間サイズの選択（またはブログのフラグメント）に関して このブログ で説明していることもあります。引用するには：

サウンドデバイスのフラグメントロジックを誤用しないでください。こんな感じです：

レイテンシはバッファサイズによって定義されます。
ウェイクアップ間隔は、フラグメントサイズによって定義されます。

バッファフィルレベルは、「フルバッファ」と「フルバッファ-1xフラグメントサイズ-OSスケジューリングレイテンシ」の間で変動します。フラグメントサイズを小さく設定すると、CPUをより頻繁にウェイクアップさせるため、CPUの負荷が増加し、バッテリー時間が減少します。 OTOHを使用すると、再生バッファーを先にいっぱいにするため、ドロップアウトの安全性が向上します。したがって、フラグメントサイズの選択は、消費電力とドロップアウトの安全性の間でニーズのバランスをとる必要があるものです。最近のプロセッサとLinuxのような優れたOSスケジューラでは、フラグメントサイズをバッファサイズの半分以外に設定しても、あまり意味がありません。

...（ああ、ALSAは上記の「フラグメント」と呼んでいるものに「期間」という用語を使用しています。これは同義です）

したがって、基本的には、通常、periodを2に設定します（参照した howto で行ったように）。次に、_periodsize * period_はバイト単位の合計バッファーサイズです。最後に、 latency は、その多くのサンプルのバッファリングによって引き起こされる遅延であり、サンプルが再生されるレートでバッファサイズを除算することで計算できます（つまり、式コードコメントのlatency = periodsize * periods / (rate * bytes_per_frame)）。

たとえば、 howto のパラメータ：

  • 期間= 2
  • periodsize = 8192バイト
  • レート= 44100Hz
  • 16ビットステレオデータ（フレームあたり4バイト）

合計バッファーサイズ__period * periodsize = 2 * 8192 = 16384_バイトに対応し、待ち時間は16384 /（44100 * 4）〜0.093`秒です。

また、ハードウェアにはサポートされている期間サイズのサイズ制限がある場合があることに注意してください（ このトラブルシューティングガイド）を参照 ）

13
SleuthEye

アプリケーションがサンプルをバッファーに書き込もうとすると、バッファーが既にいっぱいの場合、プロセスはスリープ状態になります。割り込みによってハードウェアによって起こされます。この割り込みは、各期間の終わりに発生します。

バッファーごとに少なくとも2つの期間が必要です。それ以外の場合、ウェイクアップが発生したときにバッファーはすでに空であり、アンダーランが発生します。

期間の数を増やす（つまり、期間のサイズを減らす）と、スケジューリングや処理の遅延によるアンダーランに対する安全マージンが増えます。

レイテンシはバッファサイズに比例します。バッファを完全にいっぱいにすると、最後に書き込まれたサンプルは、他のすべてのサンプルが再生された後でのみハードウェアによって再生されます。

4
CL.