07/21 15:55 第２オーディオバッファは、タイミングにシビアな第１オーディオバッファの要求を安定して受け止めるだけの余裕として、数倍の容量が必要になる。最低でも２倍、普通は４?８倍程度。第１バッファが64サンプルなら、第２バッファは256?512サンプル
(keza)
07/21 16:00 この容量の大きさが「遅延量」になる。48kHzだと512サンプル≒10msec程度で、不自然さを感じさせないぎりぎりくらいの値。なおAndroidだと第１オーディオバッファが512サンプル以上の端末が昔は多く、これが「Androidがオーディオアプリを苦手としている理由」のひとつ
(kore)
07/21 16:04 @AoiMoe 普通はサンプル通りに作ると「オーディオスレッドはコールバックを登録するスレッドから新たに作成」になっているはずなんですけどねぇ…
(sase)
07/21 16:34 なお、この話をX68のPCM8に置き換えると「オーディオバッファコールバック＝DMA転送終了割り込み」「第１オーディオバッファ＝割り込みでDMA転送するPCMバッファ」「第２オーディオバッファ＝次にDMAに設定するPCMバッファ」「第１バッファ量＝96」「第２バッファ量＝２倍」
(seho)
07/21 16:41 で、第２バッファへの充填の際に「８本のADPCMバッファから96サンプルずつをデコードして全部加算、再びADPCMに変換して第２バッファへ充填する」という処理を行っていたということに相当する
(sose)
07/21 16:51 ちなみに、今時のDAWで使われているリアルタイムオーディオ処理はPCM8と比較して、「１トラックあたり２倍のチャンネル×数倍の精度×数倍のサンプルレートのデータ」に対して「数十倍の演算処理」を「十倍以上の本数のトラック」分だけ処理することに相当する。あんまり変わらないのよ :D
(tane)
07/21 16:58 (
@CMOStone)
@gorry5 今時のDAWの場合、ストリームにしろソフト音源にしろ全ての音が一旦CPU処理下に入るので、「システム自体が持つ、音源同士の発音遅延」はゼロですが、PCM8を使い始めた頃はFMパートに対する遅延が気になりました。
(tito)
07/21 17:09 @CMOStone 今時のPCだと、たとえばGIMICとソフト音源をリアルタイム同期させようとしたら、同じような（あるいはもっと大きい）遅延問題が発生することになります… :D
(teke)