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

CPU全体の余裕と、次の音を期限までに補充できることは別です。バッファと待ち時間の関係を理解し、再現条件の比較から音切れの瞬間の記録へ進みます。

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

問題・質問

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

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

対象環境

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

仕組みの説明ではPCMのフレーム、再生バッファ、Windowsのスレッド実行とDPC/ISRを扱います。共有モードを基本の例としますが、実際の経路・バッファ量・処理周期はアプリ、API、ドライバー、機器によって異なります。すべてのアプリに共通するバッファ設定画面はありません。資料3

WPR/WPAによる記録・解析にはWindows Performance Toolkitと必要な権限を用意します。管理対象のPCでは、ツールの導入と記録を管理者に依頼してください。表示名や利用できるプロファイルは導入した版で確認します。

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

回答・解決方法

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

ただし、聞こえた「プツッ」だけではアンダーランと断定できません。音源、アプリ、音声効果、出力機器などでも似た症状が起こります。まず同じ音源で条件を一つずつ変え、元へ戻して比較します。それでも絞れなければ、音切れの前後を記録します。操作を始める場合は「手順」、結果を判断する場合は「確認」を参照してください。資料7

定義

音声再生バッファ

音声再生バッファは、このあと再生するデータを一時的にためる領域です。バッファの容量と、現在そこに入っている未再生データの量は別です。「10ミリ秒の容量がある」ことは、常に10ミリ秒分残っていることを意味しません。資料1

補充の締め切り

補充の締め切りとは、ここでは再生中のデータを使い切る前に、必要な次のデータを届ける時間上の制約を指します。音声処理は「最後には計算できた」ではなく、「鳴らす時刻までに用意できた」が必要な処理です。資料2

アンダーラン

アンダーランは、必要な供給が間に合わず、再生に使うデータが尽きる状態です。音切れやクリック音につながりますが、聞こえた症状だけでこの状態だったとは断定できません。資料2

PCMフレーム

PCMのフレームは、同じ時点に再生する全チャンネルのサンプルをまとめた単位です。ステレオだからフレーム数を2倍にして時間を計算するわけではありません。サンプルレートとフレーム数から、そのデータが表す音の長さを求められます。資料1

ISR

ISRは、機器からの割り込みに対応する処理です。割り込みに応答し、必要な処理を行います。音声との関係は、後述の「DPC・ISRと音声スレッド」で説明します。資料4

DPC

DPCは、割り込み処理を短くするため、残りの仕事を後へ回す仕組みです。通常のDPCは、同じ論理CPU上の通常のスレッドより先に実行されます。資料5、資料4

MMCSS

MMCSSは、時間制約のあるマルチメディア処理のスレッドへCPU資源を配分する仕組みです。ただし、データをディスクから先に用意したり、ロック待ちを消したりする機能ではありません。資料11

役割

補充遅れの吸収

バッファの役割は、音を用意する側と使う側の短い時間のずれを吸収し、連続した再生につなぐことです。機器が現在のデータを再生している間に、供給側が次のデータを用意します。遅れてデータが届いても、すでに聞こえた途切れをあとから埋め直すことはできません。資料1、資料2

音切れの原因調査

CPU使用率が示す一定時間内の忙しさと、音声処理が必要な瞬間に実行できたかは、見る対象が違います。調査の問いも「CPUは何%だったか」だけでなく、「音が切れた瞬間、次の音は何を待っていたか」へ変えます。資料4

構成

音声データの経路

音楽ファイルを保存しておくだけではスピーカーは鳴りません。アプリが音声データを用意し、Windowsやドライバーを通じて出力機器へ届けます。資料3

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

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

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

再生アプリ

再生アプリは、音源を読み、再生に必要なデータを用意して渡します。音源の読み込みと、出力先への供給の両方が関係します。資料1

再生バッファ

再生バッファは未再生のデータをため、消費される間に補充を受けます。供給側は残量を確認し、次のデータを渡します。資料1

オーディオエンジン

通常の共有モードでは、Windowsのオーディオエンジンが複数の音を混ぜたり、効果をかけたりします。共有モードの経路を前提とする説明であり、すべてのAPIで同じ処理を通るという意味ではありません。資料3

ドライバーと出力機器

ドライバーと出力機器は、データを機器側へ運び、再生します。機器側に処理やバッファがある場合もあり、アプリ側のバッファだけで全体の遅延が決まるわけではありません。資料3

仕組み

締め切りを削るのは計算時間だけではありません。処理を始めるまでの待ちや、必要なデータが届くまでの待ちも含みます。

データ・ロック待ち

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

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

図2: 「CPUを使っていない」は、「必要な仕事が終わっている」と同じではありません。

DPC・ISRと音声スレッド

通常のDPCやISRが動いている間、その論理CPUでは通常のスレッドを実行できません。CPU全体に余裕があっても、音声処理に必要なCPUでこれらが長引いたり頻発したりすれば、供給が遅れ得ます。資料5、資料4

Microsoftの音声・動画の性能分析資料では、ネットワーク、ストレージ、グラフィックスなどのドライバーによる長いDPC/ISRも、音切れの原因候補に挙げられています。音を出す機器だけを調べればよいとは限りません。資料6

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

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

バッファ量と再生遅延

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

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

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

「小さいほど高性能」でも「大きいほど正解」でもありません。必要な反応の速さを残しつつ、途切れない余裕を取ります。平均的な供給そのものが消費に追いつかない場合は、有限のバッファを増やしても、尽きるまでの時間を延ばすだけです。

具体例

バッファが表す時間と補充時刻の数値例に続けて、音声アプリの設計例を示します。数値は説明用の仮定であり、特定機器への推奨設定値ではありません。設計例も、任意の環境で音切れしないことを保証するものではありません。

48kHz・480フレームの音声

フレーム数が表す音の長さは「フレーム数 ÷ サンプルレート」で求めます。48kHzで480フレームなら、480 ÷ 48000秒、つまり10ミリ秒です。48kHzのままフレーム数を増やすと、ためられる音の時間も長くなります。資料1

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

残量10ミリ秒の補充

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

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

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

1秒の大半でCPUに余裕があっても、一度だけ12ミリ秒補充できない区間があれば、その一度の遅れで途切れ得ます。あとに残った処理能力の余裕は、過ぎた再生時刻を取り戻してくれません。

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

自分で音声アプリを作る場合は、次のバッファを埋める処理が毎回の期限に間に合うように設計します。WASAPIには、バッファを処理できるタイミングをイベントで受け取る方法があります。MMCSSによるCPU資源の配分を利用する場合も、データの準備や待ちを減らす設計は別に必要です。資料2、資料11

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

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

図6: 時間のかかる仕事をなくすのではなく、音を渡す直前から外します。

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

手順

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

再現条件を比較する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WPRで音切れを記録する

条件比較だけでは絞れない場合、またはドライバー側の処理を調べる場合に行います。Windows Performance Toolkit、記録に必要な権限、ETLの保存先を用意します。WPRは記録、WPAは保存した時間軸の解析に使います。資料8

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

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

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

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

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

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

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

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

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

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

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

図8: 症状が終わってからのCPU使用率ではなく、症状が起きた区間を残します。

確認

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

条件変更前後の再現性

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

音切れ前後の実行・待ち

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

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

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

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

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

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

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

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

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

flowchart TB
    accTitle: 音切れの区間で待ち方を調べる
    accDescr: 対象区間の音声スレッドについて、実行可能な状態での待ちか、データなどを待つ状態かを分け、対応する記録を照合します。
    A["音切れ前後の同じ区間"] --> B["実行可能だが順番待ち"]
    A --> C["データなどを待っている"]
    B --> D["同じCPUの処理を照合"]
    C --> E["待ちを解いた処理を追う"]

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

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

制約

音切れの原因判定

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

バッファ増量の限界

バッファを増やす調整は、一時的な供給遅れへの余裕を作るものです。継続的な供給不足や機器の切断まで解消するものではなく、遅延との引き換えになります。排他モードを使えばすべて解決するという推奨でもありません。資料2

DPC・ISRの評価基準

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

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

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

関連記事

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

参考資料

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

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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

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

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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