PCMデータのスループットが気になる…: ふんふんのブログ

Brynhildrでも指摘がある（Siegfriedでは改善済みらしい）のですが、通信帯域が狭い時に生のPCMデータはかなり重いようです。安定した有線LANならほぼ問題ないと思われますが、品質の悪い無線LANになるとプチノイズが乗る可能性があります。

素のWindowsアプリケーションならまだ軽いのですが、Qt5になるとスループットが低く、低速無線LANだとぎりぎりっぽいです。画質を程々にしないと音が間に合いません。なんか改善できるのか調べてはみますが…

プラグインコーディックを利用してCompressed Audio(MP3とか)にしたいんですが、その場合サーバ側（機能?）も作らないとなりません…大事(おおごと）になります(＠Д＠；

Brynhildrクライアント互換にして、サーバも別途作るか…。風呂敷広げすぎだな…

とりあえず、キャプチャしました。バージョンが"0.02"になった記念で。

キャプチャソフトをoCamにすると動画にマークが入らない（フリーソフトなので）ので、いいです。基本的な使い方はBandicamと変わりません。F2キーで録画終了することだけ覚えていれば大体O.K.です。YouTubeへのアップロードも問題なしです。

Windows 8.1 update 上での数時間のストレステストでは問題なし（落ちない、大きなメモリリークはなさそう）です。
Ubuntu 14.04 LTSはこれから…

VMwareで確認しましたが、画像データを同期せずに全速で表示しているので、PCMデータが置いてけぼりをくってるようです( ＾ω＾ )

実機で試そう…と思ったら、最新stableカーネル(3.14.4)が不安定(´・ω・｀)ｼｮﾎﾞｰﾝ
マシンが古いから、かも。

実機で試すと、さらに音声が置いてけぼりでございます。同期しないと…ダメだこりゃ。
そして終了時は”コアダンプ”(^-^;

＃お、助かった、実機だとgdbで止まる…。VMwareだと捕捉できません…

スタックフレームを見ると…ぐわっ、PCMデータ書き込み用のタイマーの停止を忘れてたようです…(´・ω・`)
解放済みのリングバッファにアクセスしようとしたので、コアダンプでございました、恥ずかしい。

（追記）
20分後、原因が判明しました。２つ原因がありました。

１，PCMデータ書き込み用のタイマーを止めていなかった

２，デストラクタ中のインスタンスのdeleteの順番がマズイ場所があった

QAudioDeviceインスタンスのdeleteの前に、QIODeviceインスタンスを開放しなければなりません。
厳密には、QIODeviceの開放時にQAudioDeviceの開放が行われるようです。
よってQAudioOutputのdeleteだけでよいと。

最後のコアダンプ箇所の特定は結局

cout << "Here1" << endl << flush;

をソースに入れて、いわゆるprintfデバッグを行いました。
コアダンプデバッグ終了…ι(´Д｀υ)ｱｾｱｾ

これでWindowsとUbuntuの動作差分はなくなりました。
画像とサウンド出力の同期をどうにかしないと…

ふんふんのブログ