音飛びの原因究明の結果、MMCSS、WASAPI、スレッド切り替え・・・などの方面へ行ってしまいました。
まあIEEE802.11では各種パケットを時間内に出す必要があるので
他の処理を押しのけるのもしょうがないといえばそうなんですが・・・
でも私としては無線通信が狂ってでも音を飛ばさずに流してほしいのです・・・
オンボードはバッファサイズの調節もできないし・・・
以下は今回調べて発見した情報で、確かに音声処理が優先されるはずの設定変更なので
■MMCSS （Multimedia Class Scheduler Service）
WindowsVistaから導入されていたらしいAPI。サービス名でもある。
オーディオ、ビデオ、キャプチャといったマルチメディア処理の優先度を設定する。
レジストリから変更可能で、「Audio」の初期値は優先度：6（最低）。
これを変更することが高負荷時の音飛びを改善するのかは不明。
とりあえず、「 SchedulingCategory：High、SFIO優先度：1、Background only：False、
優先度：1、ClockRate：1、GPU優先度1 」 としました。とりあえず最優先にしただけです。
（ 参考 ⇒ 『 MMCSS とスレッド優先度 』 ）
これまたWindowsVistaから導入されていたらしいオーディオAPI。
ソフトウェアがデバイスへOS側の処理なしに出力する 「 排他モード 」 が特徴的。
排他モード時には処理の減少でビットパーフェクト（再生時の再現性？）の向上と、
レイテンシ減少が期待されるが、ソフトウェア側の対応が必要。
排他モードに関して調べただけで設定変更はなし。
設定 ： 排他モード許可・優先、共有時16bit/44.1kHz、全ての効果をオフ
（ 参考 ⇒ 『 WASAPI - Wikipedia 』 ）
（ 参考 ⇒ 『 PCと音質とYouin Studio Player 』 ）
（ 参考 ⇒ 『 WASAPI共有モードのリミッターAPO 』 ）
（ 参考 ⇒ 『 WASAPI共有モード再生でビットパーフェクト出力できるか？ 』 ）
ここにWindows7における音声処理の図があります。・・・これはすごい。
audiodg.exe、audiosrv.exe、svchost.exeのそれぞれが働く位置も載ってます。
この一連の機能全てとプレイヤーの動作を最優先にすることができればなぁ・・・
■スレッド切り替え間隔
よくよく考えてみれば当たり前なのですが、CPUのコアを使用するスレッドが切り替わらない場合、
【CPUコア数＝最大スレッド数】 となってしまいます。・・・が、実際にはそうではありません。
それはCPUを使用するスレッドがある程度の間隔で切り替わるためであり、
この間隔が短いほどレイテンシは小さく、優先度は反映されやすくなるのでは、と思っています。
初期値は0x18＝011010（長い・固定・3:1）でしたが、0x24＝101000（短い・固定・1:1）に変更しました。
（※ただし、この設定はコンテキストスイッチを減らすために長くしたほうが良い、という意見もあります。）
（ 参考 ⇒ 『 CPU処理の優先度を変更 』 ）
（ 参考 ⇒ 『 PC と 音質 と オーバーヘッド 』 ）
Windowsは短い時間間隔でプロセスを切り替えて実行しているように説明したが，
実際にはスレッドを単位に切り替えているのである。
とあります。
ということは、長大な処理を持つスレッドと単純処理のみのスレッドでは処理時間が必ず異なるのだろうか。
またこのことから、スレッド処理中に切り替わることがない、ということが分かりますね。
・・・と、まあ調べたものを列挙してみました。
MMCSSがマルチメディア処理の優先度を決定しているというのは分かりましたが、
果たしてMMCSS内でのAudio優先度を上げることが
音声処理全体の優先度を上げることに繋がるのかは分かりません。
また、スレッド切り替え間隔はまだ試験中の設定です。
スレッド切り替え間隔を短くした場合のレイテンシ減少＋優先度反映を期待していますが、
処理時間が短くなりすぎて処理が十分に進む前にプロセスが切り替わったり、
ループ命令時の分岐予測などで不利になってしまうのではないか、という不安があります。
まあIntelプロセッサの賢さに期待しつつ設定を煮詰めますかね・・・
ちなみに 「 audiosrv （Windows Audio） 」 サービスのアカウントを 「 Local service 」 から
「 ローカルシステムアカウント 」 に変更したらサービスごと起動しなくなったとか
svchostの優先度が再起動したら戻ってた、などの失敗もあったりします。
まあ失敗した場合には直前に作っておいた回復ポイントで復旧させてるんですが。
あんまり容量食わないし、戻すのに時間もかからないし、きれいに戻ります。
また、関連して以下の情報も入手しました。
・ 『 スケジューリング - Wikipedia 』 ・・・ 割り込み・スレッド選択の各方法が紹介されている。
・ 『 リソーススタベーション - Wikipedia 』 ・・・ 競合の恐怖。商用OSは良くできているなぁ、と。
・ 『 デッドロック - Wikipedia 』 ・・・ 並列化の弊害。マルチコアは大変ですね。
・ 『 食事する哲学者の問題 - Wikipedia 』 ・・・ 一般化された問題はいつもシュールな名前だなぁ。
・ 『 USB音源のプチノイズ対策 』 ・・・ USB向けの設定変更。オンボードにはおそらく流用できない。
・ 『 USB音源のプチノイズ対策 その２ 』 ・・・ DLLアンロードの記載あり。どれくらい影響あるんだろう。
・ 『 Prefetchを削除する、無効にする 』 ・・・ Prefetch、Superfetchの無効化。リソースの節約に役立ちそう。
・ 『 Windows7 64bit版 インストール備忘録 』 ・・・ マルチメディア処理中の制限に関する設定の記載あり。
・ 『 ワイヤレス LAN サービスの概要 』 ・・・ wlansvcといういかにもなサービスの概要。
ただし、リソースモニターによると無線LAN使用時にCPUを占領するのは、
・ プロセス ： 「 システムの割り込み 」 ・・・ CPU使用率が急増する。
・ プロセス ： 「 System（NT Kernel） 」 ・・・ ネットワーク使用率が急増する。
・ サービス ： 「 SysMain（Superfetch） 」 ・・・ CPU使用率が急増する。
であることが分かっています。
カーネルの優先度を下げる・・・ことは不可能なのでもはや打つ手なし、かもしれません。
まあ無線LANの影響で他のプロセスがつぶされて相対的に押し上げられただけかもしれませんが。
