車輪の再発見みたいな？

出来た＼(^o^)／と思ってテスト始めて早々に不具合発覚してどうなるかと思ったけど、UAC(USB Audio Class)対応したUsbWebCamera/UsbWebCameraPro/UVCStreamerの新バージョンをもうすぐリリースしま〜す＼(^o^)／　…UAC対応と言ってもWebカメラからの音声入力しか出来へんけど^^;　多分来週半ばぐらいです。

UsbWebCamera/UsbWebCameraProは特に問題なかったんだけど、UVCStreamerでライブストリーミングする時にUACを有効(Webカメラからの音声入力を有効)にすると数秒おきに映像が止まっちゃう不具合発覚(T_T)なんでやぁ〜(汗)RTMP周りは何もいらっとらへんのに(泣)

悩むことしばし。よくよく音を聞いているとどうも早送りになってる感じ。もっもしや(^^)／と思って確認すると、やっぱり音声のサンプリングレートが問題の元凶でした。

手持ちのWebカメラからの音声入力のサンプリングレートは8, 16, 24, 32, 48, 56, 64kHzといった8kHzの倍数になっています。一方RTMPの方はCDとほぼ同じ44kHzをベースに22, 11, 5.5kHzのみの対応になっています。今はストリーミング時は44kHz固定にしているのでWebカメラから音声を取得するとサンプリングレートが必ず違ってしまっていたのです。ｶﾞ━━(;ﾟДﾟ)━━ﾝ!!

なんか邪魔臭いなぁ(´・ω・｀) と言うのも音声は映像取得よりもデータが来る頻度がすごく高いんです。手持ちのカメラだとだいたい4ミリ秒周期でデータが来ます。あっホントのデータは125マイクロ秒毎に受け取ってますけどそれがUACのプロトコル実装の辺りまで上がってくるのが4ミリ秒周期ってことです。なので通信周りが結構タイトなのです。ネイティブで実装しているとはいえユーザーランドで実装せざるをえないので他のアプリやサービスの影響を結構受けます。余計な処理はしたくないなぁ〜　映像はデータが大きい代わりにせいぜい30fpsなので33ミリ秒に1回しか来ないのに…

とは言えサンプリングレートを変換しないことにはストリーミング出来ないので変換をするようにしました。とりあえず出力は44.1kHzに固定(だってエンコーダーで保証されているのは44.1kHzだけなんだもん^^)　元音声データのサンプリングレートが低い時はゼロ挿入してアップサンプリング、高い時は間引いてダウンサンプリングすることにしました。
そう言えばネットでサンプリングレート変換って調べるとアップサンプリング/ダウンサンプリング後にローパスフィルター通せって書いてあるんですけど…
仮に32kHzのサンプリングレートでデータが来たとすると、1チャネル当たり32サンプル/1ミリ秒=128/4ミリ秒です。てことは高次のFIRのローパスフィルタ掛けるには過去のデータを数回分保持しないといけなくなるし、するとバッファ間のコピーの回数も増えるし…
一応試してみたんですが、ローパスフィルター有りでも無しでも自分には違いがわからないのでFIRでローパスフィルタ掛けるのはとりあえず無しで行きま〜す^^ ええんかな？

でもよく考えると自分のアプリの場合後工程で必ずAACエンコーダー(とデコーダー)を通ってから録音再生されることになります。たぶんそこでローパスフィルタ(相当の処理が)かかってて自前でローパスフィルタ通さなくても違いがわからない、ということにしておきましょう(笑) 結局のところエンコーダー通して圧縮するってことは高周波/低周波成分はちょん切られるってことですよね？
まぁ気が向いて時間があればスペクトル測ってみるかも。