合同会社小村ソフト
相談する
メニュー

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

· 更新日: · · Windows, オーディオ, パフォーマンス, トラブルシューティング

更新履歴(初版のみ・2026年09月11日公開)
初版公開

音楽を聴いていると、ときどき「プツッ」と途切れる。タスク マネージャーを見ると、CPU使用率は10%前後。動画も動いているし、マウスも普通に動く。

「これだけ余裕があるのに、音を鳴らすくらいできないのか」と思いたくなります。

でも、音に必要なのは、たくさんの仕事を速く片付ける能力だけではありません。次に鳴らす音を、いま鳴っている分がなくなる前に用意することも必要です。この記事では、音切れの代表的な仕組みである、この「補充の遅れ」を追っていきます。1

まずは、PCで音楽を再生する場面から考えます。1〜4章で仕組みの話を終え、5章以降に調査方法をまとめました。主にWindows 11の音声出力を想定し、数値は説明用の仮定です。

1. 音は、少し先の分をためながら鳴っている

音楽ファイルがPCに保存されていても、そのファイルを置いておくだけではスピーカーは鳴りません。再生するアプリが音声データを用意し、Windowsやドライバーを通じて、音を出す機器へ届けます。通常の共有モードでは、その途中でWindowsのオーディオエンジンが複数の音を混ぜたり、効果をかけたりします。2

ここで、必要になるたびに一つずつ音を渡していたら、処理のわずかな遅れがそのまま再生に響きます。そこで、このあと鳴らす分を、あらかじめ少しためておく。この一時的な置き場が、バッファです。機器側で再生が進んでいる間に、アプリや音声処理側が次のデータを補充します。3

少し先の音をためてから再生する用意した音声データをバッファへ補充し、機器側の再生が進む間に次のデータを用意する流れです。残りを使い切る前に次の音声データを用意バッファに補充するたまっている音を再生

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

たとえば、いまバッファにあと10ミリ秒分の音が残っているとします。次の補充が8ミリ秒後にできれば、残りがあるうちにつながります。しかし、12ミリ秒後まで補充できなければ、10ミリ秒のところで在庫を使い切ってしまいます。

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

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

このように、必要な音声データの供給が間に合わず尽きるのが、アンダーランです。音切れやクリック音などにつながります。遅れてデータが届いても、すでに聞こえてしまった途切れを、あとから埋め直すことはできません。1

音声再生は、「最後には計算できた」ではなく、「鳴らす時刻までに用意できた」が必要な処理なのです。

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

2. CPUが暇でも、なぜ補充に遅れるのか

ここまで聞くと、「だからこそ、CPUが暇なら先に補充すればいいのでは」と思うはずです。

ただ、CPU使用率の数字は、音声の締め切りを守った回数ではありません。ある時間幅のCPU全体の忙しさと、音を補充する短い処理が必要な瞬間に動けたかは、見ているものが違います。全体の負荷が低いことは、音声の担当処理に毎回すぐ順番が来る保証にはなりません。4

先ほどの例で考えると、1秒の大半で余裕があっても、たまたま一度だけ12ミリ秒補充できない区間があれば、残り10ミリ秒の音はそこで尽きます。後の時間に余裕が残っていることは、その一度の遅刻を救ってくれません。

計算が遅いのではなく、動けるまで待っている

たとえば、音声データを用意する処理が、ファイルの読み込み完了を待っているとします。あるいは、アプリ内の別の処理が持つロックを待っているかもしれません。待っている間、その処理自身はCPUをあまり使いません。それでも、再生中の音は減っていきます。データ供給の遅れやスレッドの待ちは、CPUを使い切ることとは別に起こります。54

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

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

音と関係なさそうな機器にも待たされる

もう一つ、Windows側で順番が来ない場合があります。

ネットワーク機器などから通知が来ると、Windowsは割り込みに対応する処理を実行します。最初の短い処理がISRで、残りの仕事を後へ回す仕組みがDPCです。通常のDPCやISRが動いている間、その論理CPUでは通常のスレッドを実行できません。音声処理も、この影響を受けます。64

音声を動かしたいCPUで、こうした処理が長引いたり頻発したりすると、音を補充する機会が遅れます。Microsoftの音声・動画の性能分析資料でも、ネットワーク、ストレージ、グラフィックスなどのドライバーによる長いDPC/ISRが、音切れの原因になり得ると説明されています。5

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

図4: 音を出す機器だけでなく、ほかの機器の処理が間接的に影響することもあります。

つまり、「CPUが遅くて計算しきれない」だけが音切れではありません。計算を始められない、必要なデータが来ない。その待ち時間も、音にとっては締め切りを削る時間です。

3. では、音をたくさんためればよいのでは？

補充が少し遅れるなら、その遅れを吸収できるだけの在庫を持てばよさそうです。これは実際に、音声バッファを大きくする考え方につながります。

同じ条件で先にためる音を増やせば、短い補充遅れには耐えやすくなります。しかし、今度は新しく作った音が、すでにたまっている音の後ろで待つようになります。12

音楽を聴くだけなら、再生ボタンを押してから少し待つことは気にならないかもしれません。一方、PCにつないだ鍵盤を弾く場合や、マイクの声を加工して自分で聴く場合には、その待ち時間が操作と音のずれになります。

バッファの余裕と反応の遅れ先にためる音を増やすと一時的な補充遅れを吸収しやすくなる一方、新しい音が再生されるまでの待ち時間も増えます。先にためる音を増やす補充の遅れを吸収しやすい新しい音が後ろで待つ操作から音までが遅れる

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

音楽制作ソフトなどにある「128」「256」「512」といったバッファ設定も、この時間と関係します。PCMでは、全チャンネルの同じ時点のサンプルをまとめた単位をフレームと呼びます。48kHzで480フレームなら、480÷48000秒、つまり10ミリ秒分の音です。同じサンプルレートでフレーム数を増やすほど、そこに入る音の時間は長くなります。3

ここで数えたのは、そのバッファが表す音の長さです。実際にはアプリ、ドライバー、機器などの処理もあるため、鍵盤を押してから聞こえるまでの総遅延とは分けて考えます。また、Windowsのすべてのアプリが共通のバッファ設定を持っているわけではなく、選べる大きさも機器やドライバーによって変わります。2

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

4. 音に必要なのは、平均の速さより締め切りを守ること

最初の疑問へ戻ります。

CPU使用率が低いのに音が途切れるのは、全体の処理能力に余裕があることと、次の音を時刻どおりに届けられることが別だからです。

音は少し先の分をためて再生する。その在庫を使い切る前に補充する。補充が一度遅れるだけでも途切れることがあり、在庫を増やせば余裕は増すが、新しい音が聞こえるまでの時間も長くなる。

ここまでが、この仕組みの本筋です。調べるときの問いも、「CPUは何%だったか」から、「音が切れた瞬間、次の音は何を待っていたか」へ変わります。 ここから先は、実際の症状を絞るための調査編です。

5. 調査編：まず、どの組み合わせで途切れるかを確かめる

聞こえた「プツッ」だけでは、ここまでのアンダーランと決まったわけではありません。音源そのもの、アプリの処理、音声効果、出力機器など、別の問題でも似た症状になります。Microsoftの対処資料も、音声拡張、形式、ドライバーなどを確認対象に挙げています。7

最初は設定を一括で変えず、同じ短い音源を同じくらいの時間再生して、違いを一つずつ比べます。本番の会議や録音中ではなく、作業を保存した上で、耳に負担のない音量で行ってください。

比較する条件 分かる手がかり
手元に保存した音源と、ネット経由の再生 ネット経由の再生でだけ起きるか
同じ音源を別のアプリで再生 特定アプリに偏るか
Bluetoothなどの出力と、内蔵・有線の出力 特定の出力経路に偏るか
音声拡張を有効にした状態と無効にした状態 その効果処理との組み合わせで変わるか
DAWなどで、現在のバッファと一段大きい値 先にためる余裕を増やすと変わるか

この順番なら、「音が切れる」という一言を、「このアプリで、この出力を使ったときだけ切れる」まで具体化できます。変更した後は元へ戻して再度試すと、たまたま症状が出なかっただけなのかも見分けやすくなります。

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

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

ただし、出力を変えるとドライバーやバッファなども変わります。「有線では切れない」なら出力経路を調べる手がかりですが、それだけで無線の電波が原因と確定するわけではありません。同様に、バッファを増やした改善は時間的な余裕が効いた手がかりであり、特定ドライバーの不具合を証明するものではありません。

音声拡張を比べる場合は、Windowsの「設定」→「システム」→「サウンド」で対象の出力を選び、利用できる環境では「オーディオの拡張機能」をオフにして試します。元の設定を控え、効果がなければ戻します。ドライバーはWindows Updateや機器メーカーの公式配布を使い、変更前後の版を記録してください。7

6. 調査編：「途切れた瞬間」を記録して拡大する

条件を比べても絞れない場合や、ドライバー側の処理を疑う場合は、短い時間の出来事を記録します。Windows Performance Recorder（WPR）は記録を取り、Windows Performance Analyzer（WPA）は記録した時間軸を詳しく見るためのツールです。8

再現する前から記録する

Windows Performance Toolkitを用意した環境で、WPRの画面から「More Options」を開きます。標準プロファイルには「Audio glitches」と「CPU usage」があります。前者を中心に、音声の不連続とCPUの動きを調べるための記録を選びます。利用できるプロファイルや表示名は、導入した版で確認してください。9

記録を開始してから、先ほど見つけた条件で音を再生します。途切れた時刻や操作を控え、再現後に「Save」で記録を終了し、ETLファイルを保存します。「Cancel」では保存されません。問題のない区間も少し含めると比較に使えます。既存の記録を停止する確認が出た場合は、別の調査を中断しないよう、開始を取りやめて担当者へ確認してください。10

音切れを含む短い記録を取るWPRで記録を開始し、症状を再現して時刻を控え、停止して保存した記録をWPAで調べます。WPRで記録開始同じ条件で音切れを再現時刻と操作を控えて保存WPAで前後の区間を拡大

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

ETLにはプロセス名やファイルパスなどが含まれ得るため、社内ルールに従い、必要な相手だけに共有します。記録には権限や追加のツールが必要な場合があり、会社のPCでは管理者へ依頼してください。記録自体の負荷で症状が変わる可能性も含め、記録の有無を控えます。全種類を長時間記録するより、目的に合った短い記録にします。イベント欠落の警告が出た記録では、見えない区間を正常と判断しないでください。10

大きな数字の順位より、同じ時間に何が起きたか

WPAでは、取得できている音声のイベントや再現時刻を基に、音切れの前後を拡大します。その同じ時間範囲で、DPC/ISRと、スレッドの実行・待ちを調べるCPU Usage (Precise)を確認します。これらのデータがない場合は、必要なイベントを取得できるプロファイルか確認して取り直します。記録がないことと、問題がなかったことは別です。49

音声に関係するスレッドが、実行可能なのに順番を待っていたのか、データなどを待って実行できなかったのかを見るのが出発点です。前者なら、そのCPUでDPC/ISRなどが長く動いていないか。後者なら、何がその待ちを解いたかを、利用できる記録やスタックで追います。実行中のスレッドが割り込みで中断される場合もあるため、Readyの時間だけに絞らず、DPC/ISRの実行区間も重ねます。4

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

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

長いDPC/ISRが見つかっても、そのモジュール名を見て、すぐに「このドライバーが犯人」とは決めません。別の時間の大きな値や、複数の機器が通る共通部分を見ている可能性があるからです。音切れとの時刻の対応、関係するCPU、条件を変えた結果を合わせ、必要なら機器メーカーへ調査を依頼します。

また、「DPCが何マイクロ秒以下なら、あらゆるPCで音切れしない」という共通の線引きはできません。資料中の評価用の警告値は、その評価の条件付きです。実際の補充期限やバッファの余裕と切り離して合否判定に使わないようにします。5

7. 開発者向け：音を渡す処理に長い待ちを持ち込まない

自分で音声アプリを作る場合も、出発点は同じです。次のバッファを埋める処理が、毎回の期限に間に合う必要があります。

WASAPIには、バッファを処理できるタイミングをイベントで受け取る方法があります。また、MMCSSを使うと、時間制約のあるマルチメディア処理のスレッドへCPU時間を配りやすくできます。ただし、これらは待ちを消す魔法ではありません。MMCSSも、音声データをディスクから先に用意してくれるわけではないのです。111

そのための設計として、ファイルやネットワークから読む処理と、音声を渡す処理を分けます。時間が読みにくい仕事は前もって行い、受け渡しには事前確保したバッファを使う。音声側では、UIの返事、長いロック、同期的なログ書き込みなどを待たずに済む形にします。これは、データ待ちと締め切りを切り離すための設計方針です。

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

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

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

利用者にプレーヤー全体の「リアルタイム」優先度を勧めるのも避けます。ほかの重要な処理を妨げる危険があり、通常のスレッド優先度を上げてもDPC/ISRやデータ待ちを解消できるわけではありません。124

8. まとめ：低いCPU使用率は、音の締め切りを守った証拠ではない

音切れを考える軸は、音をためる、使い切る前に補充する、補充に遅れると途切れる、の三つです。CPU使用率が低くても、必要な瞬間の待ちで補充に遅れることがあります。

まずは同じ音源でアプリや出力を比べ、それでも分からなければ音切れの区間を記録する。「CPUに余裕があるのになぜ」から、「その瞬間に何を待っていたか」へ進むと、次に調べる対象が見えてきます。

関連記事

参考リンク

  1. Microsoft Learn, Exclusive-Mode Streams. バッファ供給の時刻と音声のグリッチ、遅延との調整、イベント駆動の供給。排他モード自体を一律に推奨するものではありません。 ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, Low Latency Audio. Windowsの音声経路、バッファ・機器・効果処理と遅延、低遅延のトレードオフ。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Rendering a Stream. 再生バッファへの供給、残量、実際のバッファサイズ、PCMフレームの定義。 ↩ ↩2 ↩3

  4. Microsoft Learn, CPU Analysis. 論理CPU、スレッドのReady/Waiting、DPC/ISRとスレッド実行の関係、WPAのCPU解析。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Microsoft Learn, Results for the Streaming Media Performance Assessment. 長い・頻繁なDPC/ISR、データ供給不足と音声のグリッチ。評価の警告値をすべての機器の安全基準には一般化しません。 ↩ ↩2 ↩3

  6. Microsoft Learn, Introduction to DPCs. 割り込み処理を短くし、残りの仕事をDPCへ回す仕組み。 ↩

  7. Microsoft Support, Fix distorted or crackling audio in Windows. オーディオの拡張機能、形式、ドライバーなどの確認。 ↩ ↩2

  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などの標準プロファイル。 ↩ ↩2

  10. Microsoft Learn, WPR How-to Topics. 記録開始とSaveによる保存、既存セッションとの競合、個人情報とイベント欠落への注意。 ↩ ↩2

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

お問い合わせ
ブログ一覧に戻る