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 같은 메커니즘과 대기를 끌어들이지 않는 설계를 사용하고, 사용자는 먼저 재현 조건과 출력 경로를 비교합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로, 기존 자산이 남아 있는 프로젝트와 원인이 잘 보이지 않는 장애 조사에 강점이 있습니다.