音が出るまで、のこと その３

と、ここまで調べたのですが、大チョンボでございました。

別スレッドが上書きしていると予想したのですが、これが間違っていました…

BrynhildrサーバがPCMデータを送って来る時にPCMデータの前にPCMデータに関する情報を事前に送ってくるのですが、これの解釈が間違っていました。ヘッダーの中にサンプルレート値の情報があり、サンプルレート値が入ってくることもあれば、この値が0の場合も存在します。これまで0の場合は無効データだろうと勝手に判断して直後に送られてきたデータはリングバッファに入れていなかったのです。実はサンプルレートが0の場合は単にPCMデータの設定情報は前送ったのと変わらないから、再設定する必要はないよということらしいです。

作者の方に確認すれば、済んだ話だったみたいです。はぁー…全く。

受信データのファイルへの出力が以下です。

「output_trim2.wav」をダウンロード

リングバッファ実装版の受信データのファイルへの出力が以下です。

「output_buf2.wav」をダウンロード

私の耳では同じに聴こえます(^_^; Stirlingによるバイナリ比較でも差異がないことを確認しました。

スレッドの制御も必要なかったみたいですが、念のためQReadWriteLockによる排他制御は実装しておくことにします。

クラスのプライベートメンバに

QReadWriteLock lock;

を追加します。QReadWriteLockヘッダのインクルードも必要です。

で、バッファへの書き込み時の前でlock.lockForWrite()を呼び出し、書き込み直後にlock.unlock()を呼び出します。具体的なコードは以下の様な感じです。

// lock
lock.lockForWrite();
writtenSize = soundBuffer->put(buffer, recievedSize);
// unlock
lock.unlock();

うーん、これでO.K.なのかなぁ…

とりあえず、リングバッファへのバッファリングはうまくいきそうです。今の所タイマーを使って定期的に再生用バッファへの書き込みを行っていないので、データの消費が行われず、結果バッファが溢れ、その溢れた時点でのエラー処理の暫定実装としてバッファの内容をファイルへの書き出すようにしています。

ドキュメントのサンプルソースの通りに、20ms～40msで関数を起動し、再生用バッファへの書き込みを実装します。これでPCMデータを定期的に消費していくので、バッファが溢れることはなくなるはずです。

ついに音が出るのでしょうか。その４へつづきます…