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