Почему звук прерывается при низкой загрузке CPU? — разбираемся через буфер и сроки

Слушаете музыку, и время от времени звук прерывается щелчком. В диспетчере задач загрузка CPU держится около 10%, а нестабилен только звук. Почему в такой ситуации звук прерывается, хотя у CPU есть запас?

Даже при низкой загрузке CPU звук может прерываться, если следующие аудиоданные не успевают поступить к сроку пополнения. Дело в том, что следующую порцию данных нужно передать, пока воспроизводится звук, оставшийся в буфере. Пополнение может запоздать из-за ожидания данных или блокировок, из-за DPC/ISR на нужном логическом процессоре и т. п., и это случается, даже когда мощность CPU в целом не исчерпана. Exclusive-Mode Streams, CPU Analysis

Однако по одному лишь услышанному щелчку нельзя утверждать, что произошло опустошение буфера (underrun). Похожие симптомы возникают и из-за источника звука, приложения, звуковых эффектов, устройства вывода и т. п. Сначала на одном и том же источнике сравнивают результаты, меняя по одному условию и возвращая его обратно, а если так сузить круг не удаётся, записывают, что происходит до и после прерывания. Fix distorted or crackling audio in Windows

В этой статье разбирается этот вопрос и те, что за ним следуют: «Не увеличить ли просто буфер?» и «Что сравнивать и что записывать, чтобы сузить круг причин?». Статья не устанавливает причину конкретного сбоя по одной лишь загрузке CPU или услышанному звуку.

Рассматривается в основном вывод звука в Windows 11. Для сравнения берутся встроенный, проводной, USB- и Bluetooth-вывод и т. п., а для программ создания музыки (DAW) рассматривается и сравнение в тех случаях, когда приложение или драйвер предоставляют настройку буфера. Проектирование всего тракта записи и диагностика беспроводной связи отдельных устройств здесь охвачены не полностью.

В объяснении за базовый пример взят общий режим. Реальный путь, объём буфера и период обработки зависят от приложения, API, драйвера и устройства, и единого для всех приложений экрана настройки буфера не существует. Low Latency Audio

Приведённые здесь загрузка CPU, остаток в 10 миллисекунд, моменты пополнения и т. п. — допущения для объяснения. Это не отчёт об измерениях, в которых на конкретном ПК воспроизводилась проблема или наблюдалось улучшение. Действия во второй половине статьи — процедуры проверки, которые выполняются в вашей среде.

Механизм можно читать по порядку, начиная со следующего раздела «Буфер воспроизведения аудио». Действия для исследования прерываний звука описаны в разделах «Сравнение условий возникновения» и «Запись прерываний звука с помощью 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 показывает, насколько процессор был занят за определённый промежуток времени. Это не то же самое, что вопрос, смогла ли обработка звука выполниться в тот момент, когда это было нужно. Даже если большую часть секунды у CPU есть запас, одного-единственного участка в 12 миллисекунд без пополнения достаточно, чтобы это одно запаздывание прервало звук. Запасом вычислительной мощности, который останется потом, уже прошедший момент воспроизведения не вернуть. CPU Analysis

flowchart TB
    accTitle: Средний запас и одно запаздывание пополнения
    accDescr: Даже если большую часть секунды у CPU есть запас, один участок в 12 миллисекунд без пополнения может прервать звук.
    A["Большую часть секунды 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 выполняются раньше обычных потоков на том же логическом процессоре, и пока работает обычный DPC или ISR, этот логический процессор не может выполнять обычные потоки. Introduction to DPCs, CPU Analysis

Даже если у CPU в целом есть запас, подача может запоздать, если эти DPC и ISR затягиваются или происходят часто на процессоре, нужном обработке звука. В материалах Microsoft по анализу производительности воспроизведения аудио и видео длительные DPC/ISR драйверов сети, хранилища, графики и т. п. тоже названы среди возможных причин прерываний звука. Не факт, что достаточно исследовать только устройство, которое выводит звук. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Когда реакция на устройства задерживает выполнение аудио
    accDescr: Если на процессоре, нужном обработке звука, затягиваются обычные DPC или ISR, выполнение потока задерживается, и это может повлиять на срок пополнения.
    A["DPC и ISR на том же CPU"] -->|"Если затягиваются"| B["Выполнение аудио ждёт"]
    B --> C["Пополнение запаздывает"]
    C --> D["Остаток иссяк — звук прервался"]

Рис. 6: На пополнение аудиобуфера может косвенно влиять и обработка, не связанная с устройством, выводящим звук.

Общей границы вида «если DPC укладываются в столько-то микросекунд, звук не будет прерываться ни на одном ПК» провести нельзя. Пороговые значения предупреждений в материалах по оценке производительности относятся к условиям той оценки, и их не следует превращать в критерий безопасности в отрыве от реального срока пополнения и запаса буфера. 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

Звук 48 кГц и 480 кадров

Кадр PCM — это единица, объединяющая отсчёты всех каналов, которые воспроизводятся в один и тот же момент. То, что звук стереофонический, не значит, что для расчёта времени число кадров нужно удвоить. Длительность звука, которую представляет число кадров, вычисляется как «число кадров ÷ частота дискретизации»: 480 кадров при 48 кГц — это 480 ÷ 48000 секунды, то есть 10 миллисекунд. Если при тех же 48 кГц увеличить число кадров, удлинится и время звука, которое можно накопить. Rendering a Stream

Это время не совпадает с общей задержкой от нажатия клавиши до того момента, когда звук слышен. Дело в том, что добавляется ещё время приложения, драйвера, устройства, других буферов и обработки. Значения настроек DAW тоже читайте, проверяя единицы измерения и то, к какому буферу они относятся. Low Latency Audio

flowchart TB
    accTitle: Время, вычисленное из числа кадров, и общая задержка
    accDescr: 10 миллисекунд, полученные делением 480 кадров на 48000, — это время, которое представляет буфер; вместе с обработкой в приложении, драйвере, устройстве и т. п. получается общая задержка от клавиши до звука.
    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 или официальный источник производителя устройства и запишите версию и настройки до и после изменения. Заранее убедитесь, что сможете вернуться назад, а на управляемых ПК посоветуйтесь с администратором. Не считайте проблему решённой только потому, что сразу после обновления звук один раз воспроизвёлся нормально: проверьте в тех же условиях возникновения. 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. Если на управляемом ПК нужно установить инструмент и сделать запись, обратитесь к администратору. Отображаемые названия и доступные профили проверяйте в установленной версии. 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. Разделите случаи: связанные со звуком потоки были готовы к выполнению, но ждали своей очереди, или ждали данные и т. п.

   В первом случае сопоставьте, не работали ли долго DPC/ISR и т. п. на соответствующих логических процессорах. Во втором — проследите по полученным событиям и стекам, что сняло ожидание. Поскольку выполняющийся поток тоже может быть прерван, не ограничивайтесь временем в состоянии Ready и накладывайте также участки DPC/ISR. CPU Analysis

4. Запишите вместе соответствие по времени с прерыванием звука, затронутые процессоры и результаты изменения условий.

   Не делайте окончательного вывода, что причина в конкретном устройстве или драйвере, только по имени модуля длительного DPC/ISR. Возможно, вы смотрите на большое значение в другой момент времени или на общую часть, через которую проходят несколько устройств.

flowchart TB
    accTitle: Изучить характер ожидания на участке прерывания
    accDescr: Участок до и после прерывания увеличивают и смотрят состояние аудиопотока. Если поток был готов, но ждал очереди, его сопоставляют с DPC и ISR на том же CPU, а если ждал данные и т. п., прослеживают обработку, которая сняла ожидание.
    A["Увеличить участок вокруг прерывания"] --> B{"Состояние потока"}
    B -->|"Ждал очереди"| C["DPC и ISR"]
    B -->|"Ждал данные"| D["Что сняло ожидание"]

Рис. 12: Не выхватывайте только максимальные значения, а читайте их наложенными на участок, где нужна была обработка звука.

Если установить причину не удалось, передайте расследование дальше как незавершённое. Приложите версии ОС, приложения, устройства и драйвера, шаги воспроизведения проблемы, результаты до и после изменений, время возникновения, профиль сбора и сведения о том, были ли предупреждения о потерях. 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: Даже если перевести плеер на приоритет реального времени, обычный поток не обгонит DPC и ISR на том же CPU, ожидание данных и блокировок останется, и появится риск помешать другой важной обработке.
    A["Плеер на приоритете реального времени"] --> B["DPC и ISR не обогнать"]
    B --> C["Ожидание данных и блокировок остаётся"]
    C --> D["Риск помешать другой обработке"]

Рис. 15: Даже при повышенном приоритете ожидания, которые задерживают пополнение звука, остаются.

Похожие статьи

• Настройка «Планирование процессора» в Windows и фоновые службы
• Безопасно локализовать загрузку диска на 100 % в Windows
• Почему RDP тормозит при быстром канале?

Справочные материалы

• Microsoft Learn, Rendering a Stream. Подача данных в буфер воспроизведения, остаток, фактический размер буфера, определение кадра PCM.
• Microsoft Learn, Exclusive-Mode Streams. Момент подачи буфера и сбои звука, баланс с задержкой, подача по событиям. Это не общая рекомендация использовать сам монопольный режим.
• Microsoft Learn, Low Latency Audio. Аудиотракт Windows; буферы, устройства, обработка эффектов и задержка; компромиссы низкой задержки.
• Microsoft Learn, CPU Analysis. Логические процессоры, состояния потоков Ready/Waiting, связь между DPC/ISR и выполнением потоков, анализ CPU в WPA.
• 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. More Options в WPR и стандартные профили, такие как 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 пополнение может не успеть, если в этот момент обработка звука не смогла выполниться или ждала нужные данные. Не каждое прерывание звука вызвано этой причиной, поэтому нужны и сравнения со сменой устройства вывода или приложения.

Устранит ли прерывания звука увеличение аудиобуфера?

Если пополнение запаздывает временно, большой буфер иногда может поглотить это запаздывание. Однако растёт и ожидание до воспроизведения накопленного звука. Эта настройка не устраняет ни постоянную нехватку вычислительной мощности, ни отключение устройства. В приложениях и драйверах, где размер можно изменить, запишите исходное значение и сравнивайте по одной ступени.

Сколько миллисекунд звука составляют 480 кадров при 48 кГц?

480 ÷ 48000 секунды, то есть 10 миллисекунд. Один кадр PCM — это единица, объединяющая отсчёты всех каналов, относящиеся к одному моменту времени. Это значение — длительность звука, которую представляет такое число кадров, а не общая задержка с учётом устройства и приложения.

Виновник прерываний звука — драйвер с длительным временем выполнения DPC или ISR?

Он может быть кандидатом, но по одному лишь рейтингу времени выполнения этого не установить. Сопоставьте участок, где произошло прерывание звука, ожидания аудиопотока и выполнение DPC/ISR на том же CPU. Не делайте окончательного вывода о неисправности конкретного устройства или драйвера только по имени модуля и проверяйте также результаты изменения условий возникновения.

Поможет ли перевод плеера на приоритет реального времени?

В общем случае мы этого не рекомендуем. Повышение приоритета обычного потока не позволяет обогнать обычные DPC и ISR на том же CPU и не устраняет ожидание данных или блокировок. Разработчики используют механизмы вроде MMCSS и архитектуру, которая не вносит ожиданий, а пользователи сначала сравнивают условия возникновения и путь вывода.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Работает в основном с разработкой ПО для Windows, техническими консультациями и поиском причин неисправностей; сильные стороны — проекты, где остаются существующие активы, и расследование сбоев, причину которых трудно увидеть.