CPU使用率は低いのに音が途切れるのはなぜ？ ── バッファと締め切りから考える

音楽を聴いていると、ときどき「プツッ」と途切れる。タスク マネージャーではCPU使用率が10%前後なのに、音だけが安定しない。このようなとき、CPUに余裕があっても音が途切れるのはなぜでしょうか。

CPU使用率が低くても、次の音声データの補充が締め切りに間に合わなければ、音は途切れ得ます。バッファに残った音が再生されている間に、次のデータを渡す必要があるためです。データやロックの待ち、必要な論理CPU上のDPC/ISRなどで補充が遅れることは、CPU全体を使い切らなくても起こります。Exclusive-Mode Streams、CPU Analysis

ただし、聞こえた「プツッ」だけではアンダーランと断定できません。音源、アプリ、音声効果、出力機器などでも似た症状が起こります。まず同じ音源で条件を一つずつ変えて元へ戻す比較をし、それでも絞れなければ音切れの前後を記録します。Fix distorted or crackling audio in Windows

この記事ではその疑問と、それに続く「バッファを大きくすればよいのか」「何を比較し、何を記録すれば原因を絞れるのか」を扱います。CPU使用率や聞こえた音だけで、個別の障害原因を確定するものではありません。

対象は主にWindows 11での音声出力です。内蔵・有線・USB・Bluetoothなどの出力を比較対象にし、音楽制作ソフト（DAW）では、アプリやドライバーがバッファ設定を提供する場合の比較も扱います。録音系全体の設計や、機器ごとの無線通信の診断は網羅していません。

説明では共有モードを基本の例にします。実際の経路・バッファ量・処理周期はアプリ、API、ドライバー、機器によって異なり、すべてのアプリに共通するバッファ設定画面もありません。Low Latency Audio

ここで示すCPU使用率、10ミリ秒の残量、補充時刻などは説明用の仮定です。特定のPCで再現や改善を実測した報告ではありません。後半の操作は読者の環境で行う確認手順です。

仕組みは次の「音声再生バッファ」から順に読めます。音切れを調べる操作は「再現条件を比較する」と「WPRで音切れを記録する」にあります。

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

音声再生バッファ

音楽ファイルを保存しておくだけではスピーカーは鳴りません。アプリが音声データを用意し、Windowsやドライバーを通じて出力機器へ届けます。音声再生バッファはこのあと再生するデータを一時的にためる領域です。機器が現在のデータを再生している間に、供給側が次のデータを用意して補充します。Rendering a Stream

flowchart TB
    accTitle: 少し先の音をためてから再生する
    accDescr: 用意した音声データをバッファへ補充し、機器側の再生が進む間に次のデータを用意する流れです。
    A["次の音を用意"] --> B["バッファに補充"]
    B --> C["たまった音を再生"]
    C -.->|"使い切る前に"| A

図1: 再生を続けるには、音を使う側に補充が追いつく必要があります。

図1は補充と消費の関係だけを示した概念図です。実際の音声経路にある複数のバッファを、物理的に一つの領域とみなす図ではありません。Low Latency Audio

バッファの役割は音を用意する側と使う側の短い時間のずれを吸収し、連続した再生につなぐことです。ただしバッファの容量と、いまそこに入っている未再生データの量は別です。「10ミリ秒の容量がある」ことは、常に10ミリ秒分残っていることを意味しません。Rendering a Stream

ここでは、再生中のデータを使い切る前に必要な次のデータを届ける時間上の制約を、補充の締め切りと呼びます。音声処理は「鳴らす時刻までに用意できた」が必要な処理です。「最後には計算できた」だけでは足りません。供給が間に合わずに再生するデータが尽きる状態がアンダーランで、音切れやクリック音につながります。遅れてデータが届いても、すでに聞こえた途切れをあとから埋め直すことはできません。Exclusive-Mode Streams

音声データの経路

通常の共有モードでは、再生アプリが用意したデータをWindowsのオーディオエンジンが受け取り、複数の音を混ぜたり効果をかけたりしてから、ドライバーと出力機器へ渡します。再生アプリは音源の読み込みと出力先への供給の両方にかかわり、ドライバーと出力機器はデータを機器側へ運んで再生します。Low Latency Audio

flowchart TB
    accTitle: 共有モードで音声データが通る経路
    accDescr: 再生アプリが用意したデータを、オーディオエンジンが混合や効果の処理をしてドライバーへ渡し、出力機器が再生します。
    A["再生アプリ：データを用意"] --> E["オーディオエンジン：混合・効果"]
    E --> D["ドライバー：機器へ運ぶ"]
    D --> O["出力機器：再生"]

図2: 共有モードの例です。途中の処理やバッファは、APIや機器によって変わります。

機器側に処理やバッファがある場合もあり、アプリ側のバッファだけで全体の遅延が決まるわけではありません。この説明は共有モードの経路を前提にしていて、すべてのAPIで同じ処理を通るという意味ではありません。Low Latency Audio

残量10ミリ秒の補充

いまバッファに、あと10ミリ秒分の未再生データが残っていると仮定します。次の補充が8ミリ秒後なら残りがあるうちにつながりますが、12ミリ秒後まで補充できなければ、この単純化した例では10ミリ秒の時点でデータが尽きます。

flowchart TB
    accTitle: 同じ残り10ミリ秒でも補充の時刻で結果が変わる
    accDescr: 説明用の仮定として残り10ミリ秒の再生データに対し、8ミリ秒後の補充なら間に合い、12ミリ秒後なら使い切った後になることを示します。
    A["残り10ミリ秒分"] --> B{"次の補充"}
    B -->|"8ミリ秒後"| C["つながる"]
    B -->|"12ミリ秒後"| D["10ミリ秒で尽きる"]

図3: 時間を単純化した例です。補充できたかだけでなく、いつ補充できたかが重要です。

CPU使用率と補充の遅れ

CPU使用率が示すのは、一定時間内の忙しさです。音声処理が必要な瞬間に実行できたかとは、見る対象が違います。1秒の大半でCPUに余裕があっても、一度だけ12ミリ秒補充できない区間があれば、その一度の遅れで途切れ得ます。あとに残った処理能力の余裕で、過ぎた再生時刻を取り戻すことはできません。CPU Analysis

flowchart TB
    accTitle: 平均の余裕と一度の補充遅れ
    accDescr: 1秒の大半でCPUに余裕があっても、一度だけ12ミリ秒補充できない区間があれば、その一度の遅れで音が途切れ得ます。
    A["1秒の大半はCPUに余裕"] --> B["一度だけ12ミリ秒補充できない"]
    B --> C["その一度で音が途切れる"]

図4: 平均の余裕があっても過ぎた再生時刻は取り戻せません。

締め切りを削るのは計算時間だけではありません。処理を始めるまでの待ちや、必要なデータが届くまでの待ちも含みます。そのため調査の問いも「CPUは何%だったか」だけでなく、「音が切れた瞬間、次の音は何を待っていたか」へ変えます。

データ・ロック待ち

音声データを用意する処理が、ファイルの読み込み完了を待っているとします。アプリ内の別の処理が持つロックを待つ場合も同じです。待っている処理自身はCPUをあまり使いませんが、機器側では再生が続き、残りの音が減っていきます。Results for the Streaming Media Performance Assessment、CPU Analysis

flowchart TB
    accTitle: CPUを使っていない待ち時間にも再生は進む
    accDescr: 音声処理がデータやロックを待つ間、その処理はCPUを使いませんが、再生は進んで残りが減り、補充が遅れるとバッファが尽きる場合があります。
    A["音声処理がデータを待つ"] --> B["その処理はCPUを使わない"]
    B --> C["その間も再生は進む"]
    C --> D["補充が遅れると在庫切れ"]

図5: CPUを使っていないことと、必要な仕事が終わっていることは別です。

DPC・ISRと音声スレッド

ISRは機器からの割り込みに対応する処理です。DPCは割り込み処理を短くするため、残りの仕事を後へ回す仕組みです。通常のDPCは同じ論理CPU上の通常のスレッドより先に実行され、通常のDPCやISRが動いている間、その論理CPUでは通常のスレッドを実行できません。Introduction to DPCs、CPU Analysis

CPU全体に余裕があっても、音声処理に必要なCPUでこれらが長引いたり頻発したりすれば、供給が遅れ得ます。Microsoftの音声・動画の性能分析資料では、ネットワーク、ストレージ、グラフィックスなどのドライバーによる長いDPC/ISRも、音切れの原因候補に挙げられています。音を出す機器だけを調べればよいとは限りません。Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: デバイスへの応答が音声の実行を遅らせる場合
    accDescr: 音声処理に必要なCPU上で通常のDPCやISRが長引くと、スレッドの実行が遅れ、補充の締め切りに影響し得ます。
    A["同じCPU上のDPC・ISR"] -->|"長引く場合"| B["音声の実行が待たされる"]
    B --> C["次の音の補充が遅れる"]
    C --> D["残りが尽きると音切れ"]

図6: 音を出す機器以外の処理が、間接的に音声の補充へ影響する場合もあります。

「DPCが何マイクロ秒以下なら、あらゆるPCで音切れしない」という共通の線引きはできません。性能評価資料の警告値はその評価条件での値で、実際の補充期限やバッファの余裕から切り離して安全基準にはしません。Results for the Streaming Media Performance Assessment

バッファ量と再生遅延

同じ条件で先にためる音を増やせば、一時的な補充遅れを吸収しやすくなる一方、新しく作った音はすでにたまっている音の後ろで待ちます。音楽を聴くだけなら許容できる待ちでも、鍵盤を弾く場合や、マイクの声を加工して自分で聴く場合には、操作と音のずれが気になります。Exclusive-Mode Streams、Low Latency Audio

flowchart TB
    accTitle: バッファの余裕と反応の遅れ
    accDescr: 先にためる音を増やすと一時的な補充遅れを吸収しやすくなる一方、新しい音が再生されるまでの待ち時間も増えます。
    A["先にためる音を増やす"] --> B["補充の遅れを吸収しやすい"]
    B -->|"引き換えに"| C["新しい音が後ろで待つ"]
    C --> D["操作から音までが遅れる"]

図7: バッファを増やすのは、反応の速さと引き換えに余裕を作る調整です。

「小さいほど高性能」でも「大きいほど正解」でもありません。必要な反応の速さを残しつつ、途切れない余裕を取ります。

バッファを増やす調整は一時的な供給遅れへの余裕を作るものです。平均的な供給そのものが消費に追いつかない場合は、有限のバッファを増やしても尽きるまでの時間を延ばすだけで、機器の切断も解消しません。排他モードを使えばすべて解決するという推奨でもありません。Exclusive-Mode Streams

48kHz・480フレームの音声

PCMのフレームは同じ時点に再生する全チャンネルのサンプルをまとめた単位です。ステレオだからフレーム数を2倍にして時間を計算するわけではありません。フレーム数が表す音の長さは「フレーム数 ÷ サンプルレート」で求め、48kHzで480フレームなら480 ÷ 48000秒、つまり10ミリ秒です。48kHzのままフレーム数を増やすと、ためられる音の時間も長くなります。Rendering a Stream

この時間は鍵盤を押してから聞こえるまでの総遅延とは別です。アプリ、ドライバー、機器、ほかのバッファや処理の時間もあるためです。DAWの設定値も単位と対象のバッファを確認して読みます。Low Latency Audio

flowchart TB
    accTitle: フレーム数から求めた時間と総遅延
    accDescr: 480フレームを48000で割った10ミリ秒はバッファが表す時間で、アプリやドライバー、機器などの処理が加わったものが鍵盤から音までの総遅延になります。
    A["480 ÷ 48000"] --> B["バッファが表す10ミリ秒"]
    B -->|"ほかの処理も加わる"| C["鍵盤から音までの総遅延"]

図8: フレーム数から求めた時間は、総遅延の一部です。

再現条件を比較する

最初に再現する組み合わせを絞り、必要な場合だけ詳細な記録へ進みます。以下は原因を確かめるための手順で、すべての設定変更をまとめて実行する対策一覧ではありません。

作業を保存し、本番の会議や録音を終えてから、耳に負担のない音量で試してください。元の出力先、音声拡張、バッファ値などを控え、戻せる状態にします。設定が提供されていない項目は飛ばし、設定項目を出すためにレジストリなどを変更しません。

1. 同じ短い音源と観察時間を決め、元の条件で再現を確認します。

   Windowsの版、アプリ名と版、出力機器、接続方式、ドライバーの版を記録します。音切れが起きた時刻・操作・回数も残します。元の条件で再現しなければ、改善したと判断せず、再現する条件の確認に戻ります。

2. 次の表から比較を一つ選び、その条件だけを変えて再生します。

   比較する条件	調べること
   手元に保存した音源とネット経由の再生	ネット経由でだけ起きるか。同じ内容でも形式や処理経路が違えば、それも記録する。
   同じ音源を別のアプリで再生	特定のアプリに偏るか。
   Bluetoothなどの出力と内蔵・有線の出力	特定の出力経路に偏るか。
   音声拡張の有効・無効	効果処理との組み合わせで変わるか。
   DAWなどの現在のバッファと一段大きい値	先にためる余裕を増やすと変わるか。操作から音までの遅れも許容できるか。

3. 音声拡張を比較する場合は、対象の出力で設定を一時的にオフにします。

   Windowsの「設定」→「システム」→「サウンド」で対象の出力を選び、利用できる環境では「オーディオの拡張機能」をオフにします。表示や項目の有無が違う場合は、その版・機器の案内を確認してください。Fix distorted or crackling audio in Windows

4. 変更した設定を元へ戻し、同じ音源・観察時間でもう一度試します。

   「元の条件」「一つ変更した条件」「元へ戻した条件」の結果を並べます。効果のない変更は元の状態に戻してから、別の比較へ進みます。設定の組み合わせを変え続けると、何が効いたか分からなくなります。

5. ドライバーの変更を試す場合は、公式配布と復旧方法を確認してから行います。

   Windows Updateまたは機器メーカーの公式配布を使い、変更前後の版と設定を記録します。元へ戻せるかを事前に確認し、管理対象のPCでは管理者と相談します。更新直後に一度再生できただけで解決とせず、同じ再現条件で確認します。Fix distorted or crackling audio in Windows

得たい結果は「このアプリで、この出力を使ったときに再現する」のように、症状と条件を対応付けた記録です。改善した設定が見つかった場合も、原因の確定とは分けます。

flowchart TB
    accTitle: 一つの条件を変えて元に戻す比較
    accDescr: 同じ音源で再現を確認し、アプリや出力などの条件を一つ変え、元へ戻したときの結果も記録します。
    A["元の組み合わせで再生"] --> B["条件を一つ変えて再生"]
    B --> C["元に戻して再生"]
    C --> D["途切れた条件と時刻を残す"]

図9: 一度よくなったことより、条件と症状が繰り返し対応することを確かめます。

条件変更前後の再現性

「症状を抑えられた」「条件を絞れた」「根本原因を特定できた」は別の到達点です。観測できた範囲に合わせて結論を記録します。

flowchart TB
    accTitle: 条件との関連を示す三つの結果
    accDescr: 元の条件で再現し、条件を一つ変えると改善し、元へ戻すと再現すれば、その条件との関連を示す手がかりになりますが、原因の確定とは分けます。
    A["元の条件で再現"] --> B["一つ変えると改善"]
    B --> C["元へ戻すと再現"]
    C --> D["その条件との関連の手がかり"]

図10: 三つがそろっても、分かるのは関連の手がかりまでです。

低いCPU使用率は音声の締め切りを守った証拠ではありません。同時に、音切れがあったことだけで、補充遅れが根本原因だったとも言えません。音源、アプリの処理、効果、出力経路などを比較し、観測した範囲で判断します。Fix distorted or crackling audio in Windows

暫定的な回避策を採用するときは、元の設定、変更内容、観察時間、再発の有無、許容できる遅延を残します。根本原因が未確定なら、その旨も記録します。

WPRで音切れを記録する

条件比較だけでは絞れない場合、またはドライバー側の処理を調べる場合に行います。WPRは記録に、WPAは保存した時間軸の解析に使うツールです。Windows Performance Toolkit、記録に必要な権限、ETLの保存先を用意します。管理対象のPCでツールを導入して記録するときは、管理者に依頼してください。表示名や利用できるプロファイルは、導入した版で確認します。Windows Performance Recorder

ETLにはプロセス名やファイルパスなどが含まれ得ます。記録前に社内ルールと共有相手を確認し、公開の場所へそのまま添付しないでください。別の記録セッションが動いている場合は、勝手に停止せず担当者へ確認します。WPR How-to Topics

1. WPRの「More Options」を開き、目的に合う記録プロファイルを選びます。

   標準プロファイルには「Audio glitches」と「CPU usage」があります。音声の不連続とCPUの動きを調べられる設定を選びます。利用できるプロファイル・表示名・収集内容は導入した版で確認し、全種類を長時間記録する設定にはしません。Built-in Recording Profiles

2. 音切れを再現する前に記録を開始します。

   既存の記録を停止する確認が出たら、そのまま進めず開始を取りやめ、担当者へ確認します。記録なしの場合と条件をそろえ、記録自体の負荷で症状が変わる可能性も残します。WPR How-to Topics

3. 比較で見つけた条件で再生し、途切れた時刻と操作を控えます。

   症状の前後に問題のない区間も少し含めます。再現しなかった記録にはその事実を明記し、原因を捉えた記録として扱いません。

4. 再現後は「Save」で記録を終了し、ETLファイルを保存します。

   「Cancel」では保存されません。保存先、再現条件、記録の有無、イベント欠落の警告の有無を控えます。欠落のある記録で、見えない区間を正常とは判断しません。WPR How-to Topics

ETLファイルと、音切れの時刻・操作・条件のメモがそろえば、WPAで照合する準備ができています。記録を保存したことだけでは、必要なイベントが取得できたとは限りません。次の「音切れ前後の実行・待ち」で内容を確認します。

flowchart TB
    accTitle: 音切れを含む短い記録を取る
    accDescr: WPRで記録を開始し、症状を再現して時刻を控え、停止して保存した記録をWPAで調べます。
    A["WPRで記録開始"] --> B["同じ条件で音切れを再現"]
    B --> C["時刻と操作を控えて保存"]
    C --> D["WPAで前後の区間を拡大"]

図11: 症状が終わってから見るCPU使用率では足りず、症状が起きた区間の記録が要ります。

音切れ前後の実行・待ち

保存したETLと再現時刻のメモを用意します。以下はWPAでの調査の出発点です。スタックやシンボルを含む詳細な解析が必要になったら、記録の扱いに注意して管理者や開発者へ依頼します。

1. ETLをWPAで開き、取得できている音声イベントと再現時刻を基に、音切れの前後を拡大します。

   症状がない区間も比較用に残します。最大値のランキングだけを見ず、同じ時間範囲にそろえて比べます。

2. 同じ範囲で「DPC/ISR」と「CPU Usage (Precise)」を確認します。

   必要なデータがなければ、取得できるプロファイルかを確認してWPRの記録へ戻ります。記録がないことと、問題がなかったことは別です。CPU Analysis、Built-in Recording Profiles

3. 音声に関係するスレッドが、実行可能なのに順番待ちだったのか、データなどを待っていたのかを分けます。

   前者なら、関係する論理CPUでDPC/ISRなどが長く動いていないかを照合します。後者なら、何が待ちを解いたかを、取得できたイベントやスタックで追います。実行中のスレッドが割り込みで中断される場合もあるため、Readyの時間だけに絞らずDPC/ISRの区間も重ねます。CPU Analysis

4. 音切れとの時刻の対応、関係するCPU、条件を変えた結果を合わせて記録します。

   長いDPC/ISRのモジュール名だけで、特定の機器やドライバーを原因と確定しません。別の時刻の大きな値や、複数の機器が通る共通部分を見ている可能性もあります。

flowchart TB
    accTitle: 音切れの区間で待ち方を調べる
    accDescr: 音切れ前後の区間を拡大して音声スレッドの状態を見ます。実行可能な順番待ちなら同じCPUのDPCやISRと照合し、データなどの待ちなら待ちを解いた処理を追います。
    A["音切れ前後の区間を拡大"] --> B{"スレッドの状態"}
    B -->|"順番待ち"| C["DPC・ISR"]
    B -->|"データ待ち"| D["待ちを解いた処理"]

図12: 最大値だけを拾わず、音声処理が必要だった区間と重ねて読みます。

特定できなければ、未確定として調査を引き継ぎます。添えるのは、OS・アプリ・機器・ドライバーの版、再現手順、変更前後の結果、発生時刻、収集プロファイル、欠落警告の有無です。ETLは社内ルールに従い、調査を担当する相手だけに共有します。

音声アプリの先行読み込み

自分で音声アプリを作る場合は、次のバッファを埋める処理が毎回の期限に間に合うように設計します。WASAPIには、バッファを処理できるタイミングをイベントで受け取る方法があります。Exclusive-Mode Streams

MMCSSは時間制約のあるマルチメディア処理のスレッドへCPU資源を配分する仕組みです。データをディスクから先に用意したり、ロック待ちを消したりする機能は持っていません。MMCSSによる配分を利用する場合も、データの準備や待ちを減らす設計は別に必要です。Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSSが受け持つ範囲
    accDescr: MMCSSは時間制約のある処理のスレッドへCPU資源を配分しますが、データの準備やロック待ちの削減は別の設計で行います。
    M["MMCSS：CPU資源を配分"] -.->|"別に必要"| D["データの準備と待ちの削減"]

図13: CPU資源の配分と、データを間に合わせる設計は別の仕事です。

設計の方針はファイルやネットワークから読む処理と、音声を渡す処理を分けることです。時間が読みにくい準備は先行して行い、受け渡しには事前確保したバッファを使います。音声側ではUIの返事、長いロック、同期的なログ書き込みを待たずに済む形にします。

flowchart TB
    accTitle: 時間の読みにくい準備と音声の供給を分ける
    accDescr: 読み込みなどを先行処理で行い、用意したデータをバッファ経由で音声処理に渡して、締め切り直前の長い待ちを減らす設計です。
    A["先行処理でデータを準備"] --> B["事前確保した受け渡し領域"]
    B --> C["音声処理が必要な分を渡す"]
    C --> D["音声の出力先へ供給"]

図14: 時間のかかる仕事を音の受け渡しの直前から外します。

準備側が長く止まれば、この分離でも在庫は尽きます。平均処理時間だけでなく、長い処理や待ちが出た回、供給できなかった回数も、音声処理を邪魔しない方法で記録します。実際に選ばれたバッファ量と周期はAPIやドライバーから確認し、指定値がそのまま採用されたとは仮定しません。Rendering a Stream、Low Latency Audio

数値例も設計例も説明用で、特定機器への推奨設定値や、任意の環境で音切れしないことの保証ではありません。

リアルタイム優先度の影響

利用者がプレーヤー全体を「リアルタイム」優先度へ変更することは、一律には勧めません。ほかの重要な処理を妨げる危険があり、通常のスレッド優先度を上げても、DPC/ISRやデータ・ロックの待ちを解消できるわけではありません。開発ではMMCSSなどの仕組みと、長い待ちを音声の供給へ持ち込まない設計を使います。Scheduling Priorities、CPU Analysis

flowchart TB
    accTitle: リアルタイム優先度に変えても残る待ち
    accDescr: プレーヤーをリアルタイム優先度にしても、通常のスレッドは同じCPU上のDPCやISRを追い越せず、データやロックの待ちも残り、ほかの重要な処理を妨げる危険もあります。
    A["プレーヤーをリアルタイム優先度に"] --> B["DPC・ISRは追い越せない"]
    B --> C["データやロックの待ちも残る"]
    C --> D["ほかの処理を妨げる危険"]

図15: 優先度を上げても、音声の補充を遅らせる待ちは残ります。

関連記事

• Windowsの「プロセッサのスケジュール」とバックグラウンドサービス設定
• Windowsのディスク100%を安全に切り分ける
• 回線は速いのにRDPが重いのはなぜ？

参考資料

• Microsoft Learn, Rendering a Stream。再生バッファへの供給、残量、実際のバッファサイズ、PCMフレームの定義。
• Microsoft Learn, Exclusive-Mode Streams。バッファ供給の時刻と音声のグリッチ、遅延との調整、イベント駆動の供給。排他モード自体を一律に推奨するものではありません。
• Microsoft Learn, Low Latency Audio。Windowsの音声経路、バッファ・機器・効果処理と遅延、低遅延のトレードオフ。
• Microsoft Learn, CPU Analysis。論理CPU、スレッドのReady/Waiting、DPC/ISRとスレッド実行の関係、WPAのCPU解析。
• Microsoft Learn, Introduction to DPCs。割り込み処理を短くし、残りの仕事をDPCへ回す仕組み。
• Microsoft Learn, Results for the Streaming Media Performance Assessment。長い・頻繁なDPC/ISR、データ供給不足と音声のグリッチ。評価の警告値をすべての機器の安全基準には一般化しません。
• Microsoft Support, Fix distorted or crackling audio in Windows。オーディオの拡張機能、形式、ドライバーなどの確認。
• Microsoft Learn, Windows Performance Recorder。ETW記録とWPAによる分析、Windows Performance Toolkitの利用。
• Microsoft Learn, Built-in Recording Profiles。WPRのMore OptionsとAudio glitches・CPU usageなどの標準プロファイル。
• Microsoft Learn, WPR How-to Topics。記録開始とSaveによる保存、既存セッションとの競合、個人情報とイベント欠落への注意。
• Microsoft Learn, Multimedia Class Scheduler Service。時間制約のあるマルチメディア処理へのCPU資源の配分。
• Microsoft Learn, Scheduling Priorities。プロセス・スレッド優先度と、リアルタイム優先度に関する注意。

関連する記事

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

関連トピック

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

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

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

よくある質問

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

CPU使用率が10%程度なのに音が途切れるのはなぜですか？

音声には、再生中のデータを使い切る前に次のデータを補充する締め切りがあります。CPU全体の使用率が低くても、その瞬間に音声処理が実行できなかったり、必要なデータを待っていたりすると間に合わないことがあります。音切れのすべてがこの原因とは限らず、出力機器やアプリを変えた比較も必要です。

音声バッファを大きくすれば音切れは直りますか？

補充が一時的に遅れる場合には、大きなバッファで吸収できることがあります。ただし、ためた音を再生するまでの待ち時間も増えます。処理能力の継続的な不足や機器の切断まで解消する設定ではありません。変更できるアプリやドライバーでは、元の値を控えて一段階ずつ比較します。

48kHzで480フレームは何ミリ秒分の音ですか？

480÷48000秒なので10ミリ秒分です。PCMの1フレームは、同じ時点の全チャンネルのサンプルをまとめた単位です。この値はそのフレーム数が表す音の長さであり、機器やアプリを含めた総遅延ではありません。

DPCやISRの実行時間が長いドライバーが音切れの犯人ですか？

候補にはなりますが、実行時間の順位だけでは確定できません。音切れが起きた区間と、音声スレッドの待ち、同じCPU上のDPC/ISRの実行を照合します。モジュール名だけで特定の機器やドライバーの不具合と断定せず、再現条件を変えた結果も確認します。

プレーヤーをリアルタイム優先度にすると改善しますか？

一律には勧めません。通常のスレッドの優先度を上げても、同じCPU上の通常のDPCやISRを追い越せず、データやロックの待ちも消えません。開発者はMMCSSなどの仕組みと待ちを持ち込まない設計を使い、利用者はまず再現条件と出力経路を比較します。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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