まずは、出力部分。
音声データは、0x2000 (ステレオで4Kサンプル)のリングバッファを介してI2Sの出力ハードへ渡される。
バッファからは、I2Sからの割り込み駆動で、送信バッファがあるていど空くたびに I2S0_IRQHandler()が呼ばれ、前記リングバッファからI2Sの送信バッファへ詰め込む。
FMRecieverのケースでは、すべてが一つのマスタークロックからなるので音声データ生成とI2Sの送出の速度差はでないはずだが、ADCのクロックを外部から純粋なクロックを投入することを考えているので、その場合音声データの生成とコーデックでの消費のスピードのずれが積算してやがて大きくなることが予想される。
で、現在のコードをみてみると、audio_adjust_buffer( )のリングバッファの書き込みと読み出しスピードの差が積算して顕著になったときの調整コードがある。 通常は読み出しと書き込みがバッファの半分の距離にたもつので、2Kサンプル、45ms位かなぁ、のレテンシか。で、1.5Kサンプル程度ずれると読み込み位置を2Kサンプルに戻す。つまり一瞬30mSぐらい飛ぶ/戻るという勘定か。
これでもさほど悪くはないはずだが、将来何か工夫がある場所ではあると思う。
音声データは、0x2000 (ステレオで4Kサンプル)のリングバッファを介してI2Sの出力ハードへ渡される。
バッファからは、I2Sからの割り込み駆動で、送信バッファがあるていど空くたびに I2S0_IRQHandler()が呼ばれ、前記リングバッファからI2Sの送信バッファへ詰め込む。
FMRecieverのケースでは、すべてが一つのマスタークロックからなるので音声データ生成とI2Sの送出の速度差はでないはずだが、ADCのクロックを外部から純粋なクロックを投入することを考えているので、その場合音声データの生成とコーデックでの消費のスピードのずれが積算してやがて大きくなることが予想される。
で、現在のコードをみてみると、audio_adjust_buffer( )のリングバッファの書き込みと読み出しスピードの差が積算して顕著になったときの調整コードがある。 通常は読み出しと書き込みがバッファの半分の距離にたもつので、2Kサンプル、45ms位かなぁ、のレテンシか。で、1.5Kサンプル程度ずれると読み込み位置を2Kサンプルに戻す。つまり一瞬30mSぐらい飛ぶ/戻るという勘定か。
これでもさほど悪くはないはずだが、将来何か工夫がある場所ではあると思う。