>>593

割り込み内で直接デコードしちゃうのは危険ですー。
っていうほど危険じゃないのかも…。私が調べたときは、割り込み時にユーザスタックに切り替えてくれない割り込みハンドラだったので、スタックが極端に少なかったです。（今は大丈夫なのかも…）
とりあえずデコードはできているみたいなので大丈夫と仮定して次に。

16384Hzモノラル16bitの4096サンプル単位で再生しているようにみえました。
4096サンプルの演奏時間は0.25秒ですが、負荷計測してみたところ最初の4096サンプルのデコードが重くて処理落ちしているんじゃないかと思いました。
最初の4096サンプルのデコード（while(reedNeed>0)ループの所用時間）が209.268msで、次が22.791ms、37.251ms、22.740ms、37.393ms、という感じでした。
最初のフレームでも40ms残っているので間に合っているような気もしますが、とりあえず重いのは確かなのでリングバッファで8フレームくらい先読みすると（例えば今後他に重い処理を入れても平気になって）いいんじゃないかと思いました。

ov_read関数呼び出しの直後に
>volatile int i; for(i=0;i<0x10000;i++);
とか入れて、故意に重くしてみたときの音飛びと似ているように聞こえました。

最初の1フレームだけ極端に重いので、リングバッファじゃなくダブルバッファだけでも入れてみて様子を見たり…。（対処療法的なので誉められた対応ではないのですがテストで（笑））