Windowsのプロセッサのスケジュール設定 - バックグラウンドサービスとP/Eコア

「アプリを前面から外すと音がプチプチする」 「プロセッサのスケジュール を バックグラウンド サービス にすると安定した」

Windows では昔からこういう話が出ます。特にオーディオ、映像、計測、配信、常駐処理のように、UI よりも継続処理のほうが大事な場面では気になります。

ただ、この設定は魔法の高速化スイッチではありません。CPU のクロックを直接上げる設定でも、アプリを Windows サービスに変える設定でも、P コアに固定する設定でもありません。主に変わるのは、前面アプリと背後で動く処理のあいだで、CPU 時間をどう配るかです。

この記事では、プログラム と バックグラウンド サービス で何が変わるのかを、Windows スケジューラの基本、quantum（タイムスライス）、foreground の優遇、そして P コア / E コアを持つ CPU の挙動までつなげて整理します。

1. まず結論

先に要点だけ並べておきます。

• この設定が直接変えるのは、CPU の「馬力」よりも、CPU 時間の「配り方」です。
• プログラム は前面アプリを優遇しやすく、バックグラウンド サービス は前面と背後の処理をより均等に扱う方向です。
• そのため、前面 UI よりも裏で動く継続処理の締切が大事なワークロードでは、バックグラウンド サービス が効くことがあります。
• ただし、P コア / E コア CPU で「どのコアに載るか」は、今ではこの設定だけでなく、QoS、電源ポリシー、hybrid scheduling、Intel Thread Director などのほうが強く効きます。
• つまり、バックグラウンド サービス にしたからといって、「背景処理は P コアへ」「サービスは E コアへ」のような単純な話にはなりません。
• オーディオのプチプチやドロップアウトが、DPC / ISR、USB 省電力、ドライバ、thermal throttling、EcoQoS 由来なら、この設定だけでは直りません。

ひとことで言うと、この設定は CPU の周波数設定ではなく、順番待ちのルールを変える設定 です。

1.1 先に押さえておく用語

この記事では、6 章あたりまで読まないと実体が分からない用語が最初のほうに出てきます。先にまとめておきます。

この記事の知識マップ

「プロセッサのスケジュール」の設定は内部的にはWin32PrioritySeparationというレジストリ値に結び付き、foregroundとbackgroundへ配るquantumの長短と優遇度を切り替えるだけで、CPUのクロックやコア固定を直接変える設定ではない。バックグラウンドサービス側は前面優遇を弱めるため、締切に追われる音声処理などのアンダーランを軽減することがあるが、これはMMCSSが担う優先度引き上げとは別の仕組みである。現代のWindows、特にPコア/EコアのhybridなCPUでは、実際にどのコアへ配置されるかはこの設定よりもWindows QoSやIntel Thread Directorを使うheterogeneous schedulingポリシーのほうが強く効き、最小化やバッテリー駆動だけでQoSが下がりefficient core寄りに置かれることもある。原因の切り分けには、DPC/ISR遅延をWindows Performance RecorderとAnalyzerで観測する手順が有効である。

flowchart LR
    accTitle: プロセッサのスケジュール設定とQoSの知識マップ
    accDescr: プロセッサのスケジュール設定がWin32PrioritySeparationとquantum配分・foreground優遇を切り替える古い仕組みであること、MMCSSやWindows QoSがアンダーランやPコア/Eコアへの配置に効くこと、Intel Thread Directorやheterogeneous schedulingポリシーがhybrid CPUのコア選択を決めること、DPC/ISR遅延の確認手段を示す図
    processor_scheduling_setting["プロセッサのスケジュール設定"]
    windows_qos["Windows の QoS(サービス品質)分類"]
    win32priorityseparation["Win32PrioritySeparation"]
    quantum["quantum(タイムスライス)"]
    foreground_boost["foreground優遇"]
    audio_underrun["アンダーラン(underrun)"]
    mmcss["MMCSS(Multimedia Class Scheduler Service)"]
    efficient_core_placement["efficient core寄りの配置"]
    ecoqos["EcoQoS"]
    disableuserpresenceqos["DisableUserPresenceQos"]
    hybrid_scheduling_policy["heterogeneous schedulingポリシー(SchedulingPolicy等)"]
    intel_thread_director["Intel Thread Director"]
    p_core_e_core_cpu["Pコア/Eコア構成(hybrid CPU)"]
    core_parking["Core Parking"]
    dpc_isr_latency["DPC/ISR遅延"]
    wpr_wpa["WPR/WPA(Windows Performance Recorder/Analyzer)"]
    processor_scheduling_setting -->|"で構成できる"| win32priorityseparation
    quantum -->|"で構成できる"| win32priorityseparation
    processor_scheduling_setting -->|"利用する"| quantum
    processor_scheduling_setting -->|"利用する"| foreground_boost
    processor_scheduling_setting -.->|"軽減する"| audio_underrun
    mmcss -->|"軽減する"| audio_underrun
    mmcss -->|"利用する"| windows_qos
    windows_qos -.->|"原因になり得る"| efficient_core_placement
    ecoqos -->|"原因になり得る"| efficient_core_placement
    disableuserpresenceqos -.->|"防止する"| efficient_core_placement
    hybrid_scheduling_policy -->|"利用する"| windows_qos
    hybrid_scheduling_policy -.->|"利用する"| intel_thread_director
    hybrid_scheduling_policy -->|"前提とする"| p_core_e_core_cpu
    intel_thread_director -->|"前提とする"| p_core_e_core_cpu
    hybrid_scheduling_policy -->|"利用する"| core_parking
    dpc_isr_latency -->|"で確認できる"| wpr_wpa
    p_core_e_core_cpu -->|"で確認できる"| wpr_wpa
    dpc_isr_latency -.->|"原因になり得る"| audio_underrun

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全18件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. そもそもこの設定は何を変えているのか

設定画面の プロセッサのスケジュール は、Windows の古くからあるスケジューリング方針のひとつです。内部的には Win32PrioritySeparation と結び付いた、かなり歴史のある設定です。

ここでまず押さえたいのは、Windows が CPU を使うときの基本です。

• スケジューラは、まず 実行可能なスレッドの中から、優先度の高いもの を選びます。
• 同じ優先度なら、一定時間ずつ順番に 実行します。
• この「一定時間」が quantum（タイムスライス）です。

flowchart LR
    ready["実行可能なスレッド"] --> pick["スケジューラが最優先のスレッドを選ぶ"]
    pick --> run["1 quantum ぶん実行する"]
    run --> wait{"同じ優先度の待機スレッドがいるか"}
    wait -- yes --> switch["コンテキストスイッチ"]
    switch --> pick
    wait -- no --> run

プロセッサのスケジュール が主に触っているのは、この quantum の配り方 と、foreground をどれだけ優遇するか です。

ここでいう foreground は、いまユーザーが触っている前面のアプリです。逆に、裏へ回った処理、別プロセスの worker、Windows サービス、補助プロセス、常駐処理などは background 側に寄りやすくなります。

重要なのは、バックグラウンド サービス を選んでも、自分のアプリが Windows サービスになるわけではない、という点です。変わるのは サービスという名前の種類 ではなく、foreground と background の CPU 配分ルール です。ここ、名前がかなり紛らわしいです。

2.1 設定画面までの行き方

この設定は、コントロール パネルのかなり奥にあります。到達経路は 2 つです。

• Win + R から SystemPropertiesPerformance.exe を実行すると、「パフォーマンス オプション」が直接開きます。その「詳細設定」タブに プロセッサのスケジュール があります。
• 手でたどるなら、「システムのプロパティ」>「詳細設定」タブ >「パフォーマンス」の「設定」>「詳細設定」タブ、の順です。「システムのプロパティ」自体は sysdm.cpl で開けます。

選んだ結果は、レジストリの次の値に書き込まれます。

現在値だけ確認したいなら、PowerShell で読めます。設定を戻せるように、変更前の値は控えておくのが安全です。

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\PriorityControl' -Name 'Win32PrioritySeparation'

2.2 対象になる Windows と、値の意味

「パフォーマンス オプション」の プロセッサのスケジュール は、Windows 10 / Windows 11 のクライアントにも、Windows Server にもあります。ただし、同じ値でもクライアントとサーバーで解釈が違うのが、この設定の分かりにくいところです。

Microsoft のレジストリ解説では、Win32PrioritySeparation は 6 ビットを 2 ビットずつ 3 組（AABBCC）に区切ったビットマスクだと説明されています。

• 上位 2 ビット: quantum が長めか短めか
• 中位 2 ビット: quantum が可変か固定か
• 下位 2 ビット: foreground を background の何倍優遇するか（可変のときだけ効く）

そのうえで、UI の選択がそれぞれ次の値を書く、とされています（当時の UI 表記は Applications と Background services で、今の プログラム と バックグラウンド サービス に対応します）。

数値でもう一歩踏み込むと、Microsoft の解説記事では、0x26 のときの quantum は foreground が 18、background が 6、0x18 のときは両方 36 と説明されています。quantum は clock tick の 3 分の 1 単位なので、tick に直すと 前面 6 tick / 背後 2 tick と、どちらも 12 tick です。同じ記事では、x86 のマルチプロセッサ機での clock tick が 15.625 ミリ秒だった例が挙げられており、この場合は「前面が約 94 ミリ秒まで連続で走る設定」と「前面も背後も約 188 ミリ秒ずつ走る設定」の違いになります。

つまり、バックグラウンド サービス 側は 1 回に走る時間は長いが、前面だけをひいきしない 配り方です。背後の処理が「順番が回ってこない」状態にはなりにくくなります。

なお、この既定値の解釈にも OS 差があります。Microsoft の Win32_OperatingSystem の説明では、クライアント Windows は 可変長 quantum で前面アプリの quantum が長い、Windows Server は 固定長 quantum が既定とされています。レジストリ解説側も、同じ既定値 0x2 がクライアントでは「短め・可変・前面 3 倍」、サーバーでは「長め・固定・均等」を意味する、と書いています。サーバーが最初から バックグラウンド サービス 相当に寄っているのは、このためです。

ここで挙げた具体的な数値は、Windows 2000 / XP 世代の Microsoft ドキュメントと解説記事に基づくものです。レジストリ値と UI の対応は今も同じですが、実際の quantum の扱いは OS の版で変わり得るので、数値は「どのくらいの桁の話なのか」の目安として読んでください。

3. プログラム と バックグラウンド サービス で何が変わるか

両者の違いは、表で見比べると分かりやすいです。

クライアント向け Windows は、基本的に前面アプリを気持ちよく動かす方向です。だから普通のデスクトップ操作では プログラム が自然です。

一方で、話が変わるケースもあります。

• 裏でずっとバッファを埋め続けるオーディオ処理
• UI は軽いが、別スレッド / 別プロセスで継続実行しているキャプチャや解析
• 前面にブラウザや IDE を出していても、裏の処理の締切を守りたいケース
• サーバ寄り、サービス寄り、常駐寄りのワークロード

こういうときは、foreground だけを強く優遇するより、裏の処理が CPU を取り返しやすいほうが安定します。その意味で バックグラウンド サービス は理にかなうことがあります。

4. なぜ音声や連続処理で効くことがあるのか

オーディオのプチプチやドロップアウトを例にすると分かりやすいです。

音声処理は、「平均で速い」だけでは足りません。数ミリ秒ごと、あるいはもっと短い単位で、必要なタイミングまでにバッファを埋める 必要があります。平均 CPU 使用率が低くても、たまたまその瞬間に走れなければ音切れします。

具体的な状況をひとつ挙げてみます。

• 前面にはブラウザや DAW の UI や別アプリがある
• 裏では音声処理スレッドが一定周期で動いて、バッファを供給している
• 音声処理スレッドは高優先度すぎず、MMCSS や QoS も十分には使えていない
• CPU がそこそこ混んでいる

このとき プログラム だと、前面アプリ側が長めに走りやすく、裏の音声処理が「平均では問題ないのに、その瞬間だけ遅れる」ことがあります。これが続くと underrun になり、プチプチにつながります。

逆に バックグラウンド サービス へ振ると、裏の継続処理が CPU を取り返しやすくなり、締切を落としにくくなることがあります。

つまり、効いているときに起きているのは「CPU が速くなった」ではなく、

• 前面アプリの優遇が少し弱くなる
• 裏の継続処理が割り込める回数やタイミングが改善する
• 結果として deadline miss が減る

という流れです。

5. 原理 - quantum と foreground の優遇

もう少しだけ低レイヤ寄りに見ると、効き方の筋道はこうです。

5.1 quantum が長いと、同じ優先度の相手は待たされやすい

同じ優先度帯で競っているスレッドが複数あるとき、ひとつのスレッドが長めの quantum をもらうほど、他のスレッドはそのぶん待ちやすくなります。

前面アプリが優遇される設定では、foreground 側が長めに連続実行しやすくなります。すると、同じくらいの優先度の background 側は、その分だけ「今じゃない」を食らいやすくなります。

音声、映像、周期計測、ポーリング、監視のように、少しずつでも定期的に走りたい処理 では、この差が効きます。

5.2 Windows は foreground に複数の形で気を遣う

Windows はもともと foreground にかなり気を遣います。代表的なのはこのあたりです。

• 前面に来たプロセスの優遇
• 入力を受けたウィンドウを持つスレッドの優遇
• I/O 完了後のスレッドへの動的優先度ブースト

つまり、アプリを前面から外すだけで、スケジューリング上の扱いは普通に変わります。バックグラウンド サービス は、この foreground 優遇のうち、特に CPU 時間の配り方の偏り を小さくする方向だと考えると理解しやすいです。

5.3 「CPU をサボらせない」は半分正しく、半分ずれている

「CPU をサボらせない」という言い方は、感覚としては分かります。裏の処理が後回しになりにくい、という意味ではたしかにそうです。

ただ、技術的にはもう少し正確に言ったほうがよくて、実際に変わっているのは CPU のアイドル制御や周波数そのもの より、スレッドをどの順で、どれくらいの長さ走らせるか です。

だからこの設定は、

• turbo boost を上げる設定ではない
• C-state を切る設定ではない
• core parking を直接変える設定ではない
• P コア固定の設定ではない

ということになります。

6. P コア / E コア CPU ではどう効くか

ここがいちばん誤解されやすいところです。

バックグラウンド サービス にしたからといって、Windows が「背景処理だから E コア」「前面だから P コア」と単純に決めるわけではありません。現代の Windows、特に Windows 11 の hybrid CPU では、P コア / E コアの選択はもっと多段です。

6.1 名前が似ているが別物

まず、似た名前の別物が 2 つあります。

1. プロセッサのスケジュール の バックグラウンド サービス
   • 古い UI にある設定
   • 主に foreground / background の CPU 時間の配り方に効く
   • quantum と foreground boost の系統の話
2. QoS の Utility / Eco / Low など
   • 現代の Windows の power / performance 分類
   • core 選択や周波数制御にも効く
   • P コア / E コアの挙動に直接関わりやすい

この 2 つは同じではありません。

6.2 Windows 11 の QoS と visibility

現代の Windows では、priority だけでなく QoS も効きます。特に heterogenous processor、つまり P コア / E コアのような構成では、QoS が どの種類のコアを好むか に影響します。

Windows 11 のおおまかな分類はこうです。

この表は、Microsoft Learn の「Quality of Service」にある 2 つの表、つまり QoS レベルの一覧（High / Medium / Low / Utility / Eco / Media / Deadline）と、QoS 分類（ウィンドウの表示状態から QoS を決める対応）をまとめ直したものです。観測から起こした分類ではありません。同じドキュメントには、音を鳴らしていると判定されたプロセスは High として扱うという規定や、上のどれにも当てはまらないスレッドは優先度などのヒューリスティックで自動的に割り当てる、という説明もあります。

もう 1 つ、測定する人には重要な記述があります。バッテリー駆動中に一定時間ユーザー入力がないと、前面アプリの QoS が Medium へ下げられることがあるという機能です。ドキュメントには、バッテリーで性能測定をするときはこの機能を無効化すべきだと注意書きがあり、無効化の方法として HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerThrottling の DisableUserPresenceQos（REG_DWORD）に 1 を設定する手順が案内されています。入力のない自動テストで「バッテリーのときだけ遅い」が出たら、まずここを疑うのが早いです。

ここで大事なのは、最小化しただけで QoS が変わることがあるという点です。つまり、ハイブリッド CPU のノート PC では、

• アプリを前面から外した
• さらに最小化した
• その結果、QoS が下がった
• efficient core 寄りに置かれやすくなった
• 体感や締切が悪化した

ということが普通に起きます。

6.3 Thread Director と hybrid scheduling

Intel の 12th Gen 以降の hybrid CPU では、Intel Thread Director が OS にヒントを出します。Windows 11 はこれを使って、P コア / E コアの割り当てをより賢く決めます。

加えて、Windows 側には heterogenous scheduling のポリシーがあります。

• SchedulingPolicy
• ShortSchedulingPolicy
• ShortThreadRuntimeThreshold

これらは Automatic にしておくと、QoS とシステム構成を見て OS が決める仕組みです。さらに、その裏では processor power management 側の core parking engine や performance state engine も動いています。

全体像は、だいたいこう捉えると分かりやすいです。

flowchart TD
    t["Thread"] --> p["Priority / dynamic priority"]
    t --> q["QoS (High / Medium / Low / Utility / Eco / Deadline)"]
    t --> v["Visibility / audible / input state"]
    t --> h["Hybrid scheduling policy<br/>SCHEDPOLICY / SHORTSCHEDPOLICY"]
    t --> td["Intel Thread Director hints<br/>Windows 11 on Intel hybrid"]
    v --> q
    p --> s["Windows scheduler + Processor Power Management"]
    q --> s
    h --> s
    td --> s
    s --> c["P コア / E コア と周波数が決まる"]

7. どういうときに効き、どういうときには効かないか

実務的には、効きやすいケースと、別問題のケースを分けて見たほうが早いです。

7.1 効きやすいケース

こういうときは、バックグラウンド サービス が筋のよい対策になりえます。

• 前面アプリへフォーカスを移すと、裏の継続処理だけ不安定になる
• CPU 使用率は飽和していないのに、周期処理の締切だけ落ちる
• クリティカルな処理が legacy app / helper process / worker thread 側にあり、MMCSS や QoS の使い方が十分ではない
• サービスや常駐処理が主役で、前面 UI の気持ちよさより、裏処理の安定が大事

7.2 効きにくい、または別問題のケース

逆に、この設定だけでは足りない問題もあります。

• DPC / ISR 遅延が大きい
• USB controller や audio driver の不具合
• USB selective suspend やデバイス省電力の影響
• thermal throttling
• battery saver や power throttling、EcoQoS の影響
• バッファサイズが小さすぎる
• アプリがすでに MMCSS / Deadline を正しく使っており、問題が別の場所にある

特に Windows 11 + hybrid CPU のノート PC では、visibility と QoS の変化 がかなり効きます。最小化で遅くなる、バッテリーでだけ悪くなる、というなら、プロセッサのスケジュール より QoS / power 側を疑ったほうが当たりやすいです。

8. 実務での見方

実際に切り分けるなら、順番としては次が分かりやすいです。

1. 条件を固定する
   • AC 給電か、バッテリーか
   • 電源モード
   • バッファサイズ
   • foreground / visible / minimized の状態
2. プログラム と バックグラウンド サービス を同じ条件で比べる
   • 体感だけでなく、dropout 回数、glitch 回数、処理遅延を記録する
3. Windows 11 / hybrid CPU なら、QoS 側を疑う
   • 最小化でだけ悪化するか
   • audible 状態で変わるか
   • バッテリーでだけ悪化するか
4. 音声や映像なら、MMCSS を先に見る
   • 重要スレッドが Windows に「これは締切が大事だ」と伝わっているか
5. それでも直らなければ、DPC / ISR / USB / driver を掘る
   • ここはスケジューラ以前の話になる

8.1 それぞれ、何をどう確認するか

「疑う」で止まらないように、確認の手立てを並べておきます。

wpr は Windows Performance Recorder のコマンドで、Windows ADK に含まれています。管理者権限のコンソールから実行します。

実務では、平均 CPU 使用率より 「締切に間に合ったか」 のほうが大事です。ここ、かなり本質です。

9. まとめ

プロセッサのスケジュール を バックグラウンド サービス に変えると何が起きるかを、かなり短く言い直すとこうです。

• 変わるのは CPU の速さそのものではなく、foreground と background のあいだの CPU 時間の配り方
• プログラム は前面アプリを気持ちよくしやすい
• バックグラウンド サービス は裏の継続処理が押し負けにくくなる
• そのため、音声、映像、キャプチャ、監視、常駐処理のように、裏の締切が大事なケースでは効くことがある
• ただし、P コア / E コア CPU では、実際の core 配置は QoS、power policy、hybrid scheduling、Thread Director なども強く効く
• だから今どきの Windows では、この設定は 効くことはあるが、単独の主役ではない と見るのが自然

要するに、これは CPU の馬力を上げるつまみではなく、仕事の割り振りを変えるつまみ です。

前面アプリのキビキビ感を優先するか、裏の継続処理の締切を守りやすくするか。そのバランスを、少し background 側へ寄せる設定だと考えると、かなり腑に落ちます。

そして hybrid CPU 時代には、その上にさらに QoS と P / E コア選択の層が載っています。ここまで含めて見ると、「なぜ効くことがあるのか」「なぜ効かないこともあるのか」が見えてきます。

10. 参考資料

• Sawady: バックグラウンドサービスを優先する設定（CPUをサボらせない）
• Microsoft Learn: Win32_OperatingSystem class
• Microsoft Learn: Win32PrioritySeparation レジストリ値の説明 - ビットの意味と、UI の選択が書き込む値。
• Microsoft Learn: Master Your Quantum - Win32PrioritySeparation の値ごとの quantum。
• Microsoft Learn: Know Thy Tick - clock tick と quantum の関係。
• Microsoft Learn: CPU Analysis in Windows Performance Analyzer
• Microsoft Learn: Windows Performance Recorder
• Microsoft Learn: Priority Boosts
• Microsoft Learn: Window Features
• Microsoft Learn: Quality of Service
• Microsoft Learn: SetThreadInformation function
• Microsoft Learn: SetProcessInformation function
• Microsoft Learn: Multimedia Class Scheduler Service
• Microsoft Learn: Processor power management options overview
• Microsoft Learn: SchedulingPolicy
• Microsoft Learn: ShortSchedulingPolicy
• Microsoft Learn: ShortThreadRuntimeThreshold
• Intel Support: Is Windows 10 Task Scheduler Optimized for 12th Generation Intel Core Processors?
• Intel White Paper: Intel performance hybrid architecture & software optimizations, Part Two

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

「プロセッサのスケジュール」を「バックグラウンドサービス」にすると何が変わりますか？

変わるのはCPUの速さやクロックではなく、前面アプリと背後で動く処理のあいだのCPU時間の配り方です。内部的にはWin32PrioritySeparationと結び付いた設定で、quantum（タイムスライス）の配り方とforegroundの優遇度合いに効きます。「プログラム」は前面アプリを優遇しやすく、「バックグラウンドサービス」は前面と背後をより均等に扱う方向です。なお、この設定を選んでも自分のアプリがWindowsサービスになるわけではありません。

「バックグラウンドサービス」にすると音のプチプチが直ることがあるのはなぜですか？

音声処理は平均で速いだけでは足りず、数ミリ秒ごとの締切までにバッファを埋める必要があるからです。「プログラム」設定では前面アプリ側が長めに走りやすく、裏の音声処理が平均では問題なくてもその瞬間だけ遅れてunderrunになることがあります。「バックグラウンドサービス」へ振ると裏の継続処理がCPUを取り返しやすくなり、deadline missが減ることがあります。ただしDPC/ISR遅延、USB省電力、ドライバ不具合、thermal throttling、EcoQoS由来の問題はこの設定では直りません。

「バックグラウンドサービス」にすれば背景処理がPコアで動くようになりますか？

なりません。PコアとEコアのどちらに載るかは、この設定よりもQoS、電源ポリシー、hybrid scheduling、Intel Thread Directorなどのほうが強く効きます。Windows 11ではアプリを最小化しただけでQoSが下がり、バッテリー駆動時はefficient core寄りに置かれやすくなることも普通に起きます。最小化でだけ遅くなる、バッテリーでだけ悪くなる場合は、この設定よりQoSやpower側を疑うほうが当たりやすいです。

音切れやドロップアウトの原因はどう切り分ければよいですか？

まずAC給電か、電源モード、バッファサイズ、前面・最小化の状態などの条件を固定し、「プログラム」と「バックグラウンドサービス」を同条件で比較してdropout回数や処理遅延を記録します。Windows 11のhybrid CPUなら最小化やバッテリーでだけ悪化するかを見てQoS側を疑います。音声や映像なら重要スレッドがMMCSSを使えているかを先に確認し、それでも直らなければDPC/ISR・USB・ドライバを掘ります。ここまで来るとスケジューラ以前の話になります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。