WASAPI排他モード(イベント駆動)でスレッドスケジュール精度とプチノイズ

引き続きWASAPI(サウンドプログラム)ネタ。低レベルのサウンド処理を実装したことのある人なら誰でもプチノイズとの戦いを経験したことがあるはず。先回、スレッドスケジュールの間隔が20msec以上かかると書いたが、もう少し詳細に調べてみた。

まず本当にスレッドスケジュールの間隔が遅いのかを、よくある以下のコードで実験。

001  DWORD time0 = timeGetTime();
002  for(int i = 0; i < 1000; i++) Sleep(3);
002  DWORD duration = timeGetTime() - time0;

きっちり3,000msecで抜けてきている。どうやら AvSetMmThreadCharacteristics() による精度向上はちゃんとできているみたい。

そうなると、WASAPIイベントがシグナル状態になる間隔の精度が怪しい。この WaitForMultipleObjects() から抜けてくる周期を測ってみる。

001 // 出力バッファの書き込みイベントを待つ
002 HANDLE eventArray[1] = { outputBufferEvent };
003 DWORD retval = WaitForMultipleObjects(1, eventArray, FALSE, 2000);

ループ処理1秒分の統計をとってみた。まずはバッファ長を12msecにした場合。

Loop count=52. Ave=19.327[ms] Min=15[ms] Max=25[ms] Buffering frames=0.
15 20 20 20 25 20 20 20 15 20 20 20 20 20 15 20 20 15 25 20 20 20 20 20 20 20
20 20 20 20 20 20 15 20 20 20 15 20 20 20 20 20 15 20 20 20 15 20 20 20 20 15

平均で1ループに19msecもかかっていてそもそも間に合っていない。当然音は超ノイジーで聴けたものではないレベル。どうやら最短でも20msec以上は必要そう。

次にバッファ長21msec。

Loop count=48. Ave=21.042[ms] Min=20[ms] Max=30[ms] Buffering frames=800.
20 20 20 20 30 20 20 20 20 20 20 20 20 20 30 20 20 20 20 20 20 20 20 20
30 20 20 20 20 20 20 20 20 20 30 20 20 20 20 20 20 20 20 20 30 20 20 20

20msecと30msecにそろっている。イベント間隔は20msec以上で10msecの粒度らしい。平均すると21msecで回っているけどプチノイズが聴こえる。30msec間隔があいたときに、次のバッファへの転送が間に合っていないのだろう。計算上では次のバッファ21msecの先頭9msecが失われてもまだ12msec余裕があるように考えられる。推測だが、波形データがWASAPIやドライバーを経由してUSB-DACに到達するまでの時間まで含めると間に合っていないのだと思う。

ちなみに私の XonarU7 だと IAudioClient::GetDevicePeriod() の戻り値は DefaultDevicePeriod が10msec、MinimumDevicePeriod が3msecでまったくあてになっていない。(バッファ長は MinimumDevicePeriod 3msecの整数倍にしてます。)

ではどうするのが安全なのか？バッファ長よりも長いループ間隔がかかってしまった場合でも、可能な限り失う時間が短い設定がよさそうだ。27msecで試してみた。

Loop count=37. Ave=27.027[ms] Min=20[ms] Max=30[ms] Buffering frames=0.
30 30 20 30 30 20 30 30 20 30 30 30 20 30 30 20 30 30 20
30 30 30 20 30 30 20 30 30 20 30 30 30 20 30 30 20 30

30msecで失う時間は3msec。バッファ長27msecから先頭3msecが失われても、24msecの余裕があればプチノイズは聴こえなかった。また30msecが3回続くケースがあっても問題ないようだ。

この結果は激しく環境依存。24msecがOKで12msecがNGなどとはどこにも書いてない。やはりちゃんとした安全マージンを知る方法がないのは厳しい。
結局、WASAPI排他モード(イベント駆動)でレイテンシーを攻めるのは環境依存になるので無理っぽい。いずれタイマー駆動モードも試してみて比較してみたい。

息子＆会社のメンバーでスキー

息子と会社のメンバーと言うなかなかない組み合わせでスキー行ってきました。


それぞれ別のプロジェクトを担当していて、普段職場での接点が少ないメンバーが集まってくれたのは嬉しかったですね。


最近息子は Minecraft の Lua スクリプトでプログラミングを始めました。それも含めるとプログラマー率100％。息子は部署の天才プログラマーたちとプログラムの話ができて嬉しそうでしたよ！


ちょっとハイキング。空と雪しかない景色は別世界の美しさです。


今回、息子は非圧雪斜面の面白さを発見して取り付かれてしまいました！急斜面でコケちゃったときに、半分雪に埋まりながらゴロゴロと転がり落ちるのも超楽しいです。


ゲレンデ脇のちょっとした林を見つけては分け入っていきます。私は今のデモ用の板だとちょっと辛いですね。そろそろ非圧雪＆パーク対応のツインチップ、ファットボディーの板欲しいな･･･。


締めはみつまたパークでジャンプ。まだ今シーズン回数が少ないのでジャンプの高さが足りないですね･･･。

ウィンタースポーツするメンバーが他にもいるようなので、会社外の親睦として声掛けしてまた集まりたいです。とはいえ、行き帰りは皆バラバラ、全員が集まったのはランチぐらいという一体感のなさは、いかにもプログラマーならではかと。

今日は息子と遊んでくれてありがとう！

WASAPI排他モード(イベント駆動)でスレッドスケジュールが間に合わない問題

久しぶりにプログラムネタ ＆ 唐突にWASAPI(サウンドプログラム)。

WASAPI排他モードのMSDNページ
・Exclusive-Mode Streams

WASAPI排他モードを使う目的には低レイテンシーとビットパーフェクトの実現がある。低レイテンシーに関してはMSDNサンプル内の以下のコードがポイント。

001 // Initialize the stream to play at the minimum latency.
002 hr = pAudioClient->GetDevicePeriod(NULL, &hnsRequestedDuration);
003 
004 hr = pAudioClient->Initialize(
005   AUDCLNT_SHAREMODE_EXCLUSIVE,
006   AUDCLNT_STREAMFLAGS_EVENTCALLBACK,
007   hnsRequestedDuration,
008   hnsRequestedDuration,
009   pwfx,
010   NULL);

IAudioClient::GetDevicePeriod() でサウンドデバイスの最速の割り込み間隔を取得して、その長さでバッファを初期化する。これによりそのサウンドデバイスで実現できる最も低レイテンシーでのサウンド出力が可能となる。

が、Xonar U7 でこれをやってみたら酷いノイズしか再生されない！調査したところイベント駆動されるバッファ出力ループの処理間隔がまったく間に合っていない！

001 // Each loop fills one of the two buffers.
002 while (flags != AUDCLNT_BUFFERFLAGS_SILENT)
003 {
004   // Wait for next buffer event to be signaled.
005   DWORD retval = WaitForSingleObject(hEvent, 2000);

WaitForSingleObject() でループの間隔が同期されるが、家の環境だと20msec以上かかっている。ちなみに IAudioClient::GetDevicePeriod() の値は 3msec･･･。

001 // Ask MMCSS to temporarily boost the thread priority
002 // to reduce glitches while the low-latency stream plays.
003 DWORD taskIndex = 0;
004 hTask = AvSetMmThreadCharacteristics(TEXT("Pro Audio"), &taskIndex);

MMCSS の力も及ばずか･･･。

PlayPcmWinのページでも12msecで音切れの可能性アリと報告がある。

何msecにしたら安全かを取得する方法がないのが厳しい。経験的に Sleep(0) でループを回せば CPU 時間を無駄にロックせずに、秒間1,000回以上のループがまわせるのは分かっているが、WASAPI排他モード的には行儀が悪いやり方だと思う。

しばらくは IAudioClient::GetDevicePeriod() で取得した値が30msecを超えるまで整数倍して使おうと思う。何かおかしい気がするが、WASAPIのバッドノウハウとしてメモしておく。

ちょっとお洒落なアンプケースを作った

自作マルチアンプ環境の締めくくりとして、パワーアンプのケースを作ってみました。さすがにTA2020キット×2個をバラックでってわけにもいかないですからね。


電子工作用のアルミやプラスティックのケースを使うのも簡単でいいのですが、今回はちょっとデザインしてみたかったのでMDFとアルミ板で自作してみました。アルミメッシュでフロントとリアパネルを作って中が透けて見えるようにしてあります。このアルミメッシュ、ホームセンターで売ってるのを見かけてから、いつかこんな風に使ったらカッコイイだろうなとずっと思っていました。

リアのスイッチはスピーカーラインの切断スイッチです。常識的に考えれば電源スイッチを設けるところですが、リビングのBGM用途で365日電源入れっぱなしなのでそもそも電源切ることがありません。逆に配線や設置の変更で一時的に電源切るときに、TA2020のポップノイズからスピーカーを守るために切断スイッチが必要でした。これも普通なら遅延リレー回路とかを設けるところなのですが、先ほど書いたように設置が決まってしまえば基本電源入れっぱなしなので、リレー回路組んで自動化するメリットもありません。しかも無音時のTA2020の消費電力が限りなく0に近いのに、リレー使うとそれだけで300mA(4回路なのでリレー2個は必要)も常時消費するのもバカバカしいですよね。ということでポップノイズ対策は手動スイッチとなりました。

あと、TA2020はさすがデジタルアンプだけあってほとんど発熱しないのでヒートシンク無しで問題無しです。


リアのターミナルから4ch分のスピーカーケーブルが出て行く様はちょっとカッコイイです。でもアンプの重さ(軽さ？)に対してケーブルが多すぎて、アンプが浮いちゃうのですよね。


LEDがケース内の回路を照らすのがメッシュ越しに見えるのも雰囲気あって気に入ってます。ウーファーとツイーターでボリュームが独立しているので、こちらでバランスを調整することもできます。そのうち測定機器そろえて、周波数特性そろえたいですね。


さて、今回の一連の取り組みの発端となったスピーカーの前に積まれる洗濯物の件ですが、こちらもみっともないのでケースに収まってもらうこととなりました。今まで机の上にあったスピーカーがなくなったり、アンプが超小型になったりで部屋もだいぶすっきりとしました。年末の大掃除を挟んで、部屋の模様替えとオーディオ遊びの両方ができてよかったです。何より暮らしにBGMが戻ってきたのが嬉しいですね。

foobar2000とUSB-DACでマルチアンプを構築

5.1ch出力できるUSB-DACと余ってるパワーアンプがあるならマルチアンプするしかないでしょ！ということで、foobar2000のデジタル・チャンネルデバイダーDSPを利用して、マルチアンプを構築してみました。


予備で買っておいたTA2020のキットを組み立てて、ウーファー用とツイーター用のパワーアンプをセットで用意します。


スピーカーは2Wayですが、サブウーファー用の重低音域もデジタルフィルターで分離したいので3Wayのチャンネルデバイダを使います。AEDIO様のHPで配布されているfoobar2000用の"foo_dsp_channeldividerF3B"というDSPプラグインを使わせてもらいました。
実現したいフィルター特性の設定パラメータ(FIRフィルタのタップ数)を求める為に、同時に公開されているクロスシミュレーションを使います。今回はサブウーファーを120Hz、ツイーターを5kHzのクロスオーバーとし、それぞれ-144dB/octというデジタルフィルターだからこそ実現できる急峻なカットオフ特性とします。サブウーファー側が PassBand 80Hz ～ StopBand 160Hz で 5,223Taps、ツイーター側が 3.3kHz ～ 6.6kHz で 127Taps となりました。


DSPプラグインの設定画面だとこんな感じです。クロスオーバー領域の周波数特性をフラットにするための係数補正(adjust Cofficient)を有効にしているので、MidのFIR Tapsは影響ないようです。
サブウーファーで低音域を補強するのでバッフルステップ補正は使ってません。オーバーフローによるクリッピングの発生を抑えるために-3.0dBのGain設定が推奨されていますが、まあ普通の音楽ソースでそれが必要なシチュエーションもないでしょうから、自己責任で0.0dBとしてます。ツイーターに1Tap、7.8mm相当の遅延を設定しているのは、スピーカーウーファーとツイーターの前後位置あわせを意識してですが、聴いてて差は分かりませんでした。


"foo_dsp_channeldividerF3B"の出力チャンネルは低音域から0ch(L)、1ch(R)、中音域が2ch(L)、3ch(R)･･･、となっていて、一般的な5.1chのチャンネル割り当てとは一致していません。それを入れ替える為に"foo_channel_mixer"というDSPプラグインを合わせて使います。こちら横軸が入力、縦軸が出力のマトリクスになっていて、そこに係数を入れることでチャンネルの入れ替えとか振幅の変更、マイナス値を入れれば位相反転もできます。
まず120Hz以下の帯域が来ている0chと1chを、0.5の係数かけてモノラルに合成した上でサブウーファー用のLFEに流します。ウーファー用の中音域をFLとFRに、ツイーター用の高音域をBLとBR(リアスピーカー用のチャンネル)に流し、それぞれUSB-DACから各音域用のパワーアンプに接続します。


スピーカーの裏はこんな感じですね。雑誌の付録スピーカーのために天井に4ch分のスピーカーケーブルが通っているのは明らかにやりすぎな感じです。

ここまでやって音的にどうかと言うと、直前のツイーターに4.2kHzのハイパス入れただけの状態がやはりハイ上がりの特性だったようで、そこからの変化と言う点では音がおとなしくなっちゃった、というのが正直な印象でした。でもしばらく聴いているうちに、高音域のクリアさの点で良さが見えてきて、全体としては音量を上げてもうるさくならない、余裕のあるシステムができました。8cmの入門用ウーファーに無理して広い帯域を任せていないのが勝因かと思ってます。デジタルフィルター使って120Hz～5kHzを-144dBでバンドパスしているので、低音による音の歪とか、高音域にペーパーコーンの色が乗ったりとかを排除できてるんですね。

サブウーファーがあるとはいえ、￥3,800の雑誌の付録スピーカーとは思えない鳴りっぷりに、デジタルフィルター使ったマルチアンプシステムの可能性を感じました。しかもアンプもたった￥1,200×2個ですよ！ USB-DACも1万円程度のエンターテイメント向け商品ですし、これはオーディオの価格破壊ですね。これでスピーカーユニットをちょっといいのに変えたら、リビングでのBGM用途ならそれ以上を目指す必要ないんじゃないかな、というぐらいの音質になると思ってます！

ママチャリGP参戦！

いつも筑波8耐に参加してくれる痛ジャージのHさんのお誘いで、ママチャリGPなる自転車レースに初参戦してきました。


一周4.56Kmの富士スピードウェイを舞台に7時間の耐久レースです！F1だって開催できちゃう本格的なサーキットで自転車レースとは贅沢！


でも競技車両はママチャリ限定。このママチャリってののレギュレーションが妙に厳格に定義されてて笑えます。
- サドル高83センチ以下
- ハンドル高95センチ以上
- ママチャリの勇姿と気品が保たれていること！(？)
- 車輪は26インチ
- ギア無しを強く推奨 (ギア装備車は軟弱仕様として格下カテゴリ扱い)
- 無改造(装飾への投資は許可)
- 前カゴ必須
- 補助輪の使用は不可

車両規定を見ると大会主催者のママチャリに対する強い思い入れが伝わってきます。


中学生が乗っている通学自転車の一部はママチャリと認められないみたいですね。(ママは通学しないからママチャリじゃないという解釈もできそう･･･)


過去にこういうレギュレーションの隙間を突くような車両がいたんですね。ライダーの服装から本気度が伝わってきますが卑怯者扱いです。


ここまでレギュレーションうるさいのは皆が必死で勝敗を戦うからかと思いきや、大半の人が登り勾配になると自転車降りて押してる有様。これはいったいどういうこと！？


パドックではテント張ってBBQやってるひとがいっぱいいるし、ピット内ではコタツとかストーブ持ち込んでダラダラしてるし、レースと言うよりは何かのお祭りですね。


私はそのあたりの雰囲気よく分かってなかったのでサイルジャージの正装で行ってしまいましたが少数派でした。


半数ぐらいのチームが大小さまざまな仮装を楽しんでます。ガンダムに乗ったシャアが子供を追い回してましたよ。


中でも一番完成度が高かったのはこのアキラのバイク！遠目でみると本当にバイクに見えちゃいます。ペダルを漕いだりハンドル操作できるような空間を確保しつつフルカウルを乗せてしまう造形技術は凄いの一言！

筑波8耐とは参加している人のカテゴリがまったく違いますね。筑波はロードバイクそれなりに本気でやってる人ってくくりで分かりやすいのですが、こちらはどんな人たちなんでしょうか？こんなクソ寒い中わざわざ自転車て遊ぼうなんて、普通の感覚じゃないですよね！

あまりに楽しかったので来年はぜひ家族とともに参戦したいと思ってます。ただ、富士スピードウェーの後半の登りはそれなりに厳しいので、足つきせずに登ろうと思うと結構ハードな運動になるのでなめてかかってはいけません。

伝説のアンプ、TA2020キットを作ってみた

サブウーファー導入時にボリューム調整をPC側でやるコトになったため、これまで使っていたプリメインアンプは別の用途に使うことにして、パワーアンプとしてFOSTEXの小型アンプAP05を導入してみました。元々スピーカー工作入門用に企画されたアンプなので、雑誌の付録スピーカーを鳴らすにはベストチョイスで何の不満もないアンプだったのですが、深夜なんかに極小音量で使っていると入力信号無しと誤認識してスタンバイモードに落ちてしまう問題が発生。サブウーファーだけが悲しくブーブー鳴っているという状況になってしまうので、残念ながらAP05は早々に引退となってしまいました。


ネットでアンプのことを調べていたら、TA2020というICを使ったデジタルアンプが安くて音がいいと評判になっていることを発見。Amazonで中華アンプとして2～3千円ぐらいで売っているのですが、製造の当たり外れとか、中華アンプのさらに偽物が届くとか、結構怖いことが書いてあったので、キットを買って自作することにしてみました。キットはNFJさんのTA2020デジタルアンプ自作キットを購入。それなりに音質にこだわった部品選定で1セット￥1,200ぐらいと激安です。お一人様3セットまでと書いてあったので、使う用、失敗したときの予備、保管用と意味もなく3セット買ってしまいました。


これがTA2020-20というデジタルアンプIC。メーカーのTripath社がすでに倒産していて、どこかからかかき集められた中古ICが販売されているのですが、何十万円もするピュアオーディオ用のアンプに音質で勝ったとか、都市伝説ぽい評判をネット上でたくさん見かけます。


ネットに製作記事がいくつかあるので、特に悩むことなくサクッと完成。AP05と同じくらいのサイズですね。

オーディオマニアが言うような音質の良し悪しとか分からないのですが、PA05もTA2020も、普通に使っていればどちらも不満のない音質です。強いて言うなら5W+5WのPA05だと大音量でメタル聴くぜ！って時にちょっとパワー不足で音が歪む感じがするのですが、20W+20WのTA2020だとその程度の音量でも余裕で鳴らせるのがアドバンテージでしょうか。でもリビングのBGMとして常用するよりははるかに大きい音量での話ですけどね。

久しぶりに半田ごて握って電子工作したのですけど楽しいですね。しかもたった￥1,200で十分な音質のアンプが手に入っちゃうあたりのお得感もたいへんよろしいです。コンデンサー交換に続き、自作アンプの満足度がプラスされてより気に入ったオーディオ環境になってきました。もっと色々とやってみようと思います。

宝台樹でファミリースキー

冬休みの最後、家族総出で宝台樹でスキーしてきました。妻と娘は今シーズンのスキー初めです。


天気予報では曇りだったのですが、午前中は快晴で素晴らしい景色を堪能できました。湯沢も候補だったのですが、相対的にこちらの方が天気よさそうだったので宝台樹へ来たのですが正解でした。


受験生の娘もスキーです。本番の分まで今のうちに滑っておきましょう！･･･って世間とは逆の発想です。学校のスキー合宿を控えた娘のお友達もお誘いして闇練です。この二人、どんな斜面でも超安定したボーゲンで一定の速度で滑って行きます。本人たちの性格そのままの滑りなのですが、斜面に張り付いているような運動は見ていて面白くないです。


対して妻は色々と笑わしてくれるので楽しいです。


息子のほうは相変わらず躍動感のある滑りをするのですが･･･


何かちょっと我流が強くなってきていて、様になっていない感じです。


雪面を踏めてはいるのですが、エッジが浮いてしまってますね。これはイカン。去年レッスンを受けてとてもよかったので、今年も講習を受けて我流を補正しなければいけませんね。

宝台樹は2回目なのですが、上級コースは距離がそこそこあって滑りがいがあるのでお気に入りのスキー場になりました。新潟の天気が悪そうなときはこちらですね。