KomuraSoft LLC
Связаться с нами
Меню

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

· Обновлено: · · Windows, Аудио, Производительность, Устранение неполадок

Слушаете музыку, и время от времени она с щелчком прерывается. Открываете диспетчер задач — загрузка CPU около 10%. Видео идёт, мышь двигается как обычно.

Хочется спросить: «Неужели при таком запасе мощности нельзя даже воспроизвести звук?»

Но звуку нужна не только способность быстро выполнять большой объём работы. Нужно ещё и подготовить следующую порцию звука прежде, чем закончится та, что звучит сейчас. В этой статье мы разберём именно это запаздывание пополнения — типичный механизм прерываний звука.1

Начнём с обычного случая: воспроизведение музыки на ПК. Разделы 1–4 описывают механизм, а с раздела 5 идут методы расследования. Предполагается в основном вывод звука в Windows 11, а числа — допущения для объяснения.

1. Звук воспроизводится, пока в запасе есть немного следующего

Даже если музыкальный файл сохранён на ПК, от того, что он просто лежит на диске, динамики не зазвучат. Приложение воспроизведения готовит аудиоданные и передаёт их через Windows и драйвер устройству, которое создаёт звук. В обычном общем режиме по пути аудиодвижок Windows микширует несколько потоков и применяет эффекты.2

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

Накопить немного звука вперёд и затем воспроизвести егоПоток, в котором подготовленные аудиоданные пополняют буфер, а следующая порция готовится, пока воспроизведение идёт на стороне устройства.Пока остаток не исчерпанПодготовить следующие аудиоданныеПополнить буферВоспроизвести накопленный звук

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

Допустим, сейчас в буфере осталось ещё 10 миллисекунд звука. Если следующее пополнение удастся выполнить через 8 миллисекунд, оно подоспеет, пока остаток ещё есть. Но если пополнить не удастся вплоть до 12 миллисекунд, на отметке 10 миллисекунд запас иссякнет.

Те же 10 миллисекунд остатка, но результат зависит от момента пополненияКак допущение для объяснения показано, что при 10 миллисекундах оставшихся данных воспроизведения пополнение через 8 миллисекунд успевает, а через 12 миллисекунд приходит уже после исчерпания запаса.Сейчас осталось 10 миллисекундПополнение через 8 мсПодоспеет, пока остаток естьПополнение через 12 мсЗапас исчерпан на 10 мс

Рисунок 2: упрощённый пример в терминах времени. Важно не только то, удалось ли пополнить, но и когда именно.

Когда нужные аудиоданные не поступают вовремя и запас иссякает, возникает аудио-underrun. Он приводит к прерываниям звука, щелчкам и подобным дефектам. Даже если данные придут с опозданием, уже услышанный разрыв задним числом не заполнить.1

Воспроизведение звука — это задача, где недостаточно «в конце концов вычисление завершилось»; требуется «всё было готово к моменту, когда должно было прозвучать».

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 5, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Почему пополнение запаздывает, даже когда CPU простаивает

После всего этого естественно подумать: «Так почему бы, раз CPU свободен, не пополнять буфер заранее?»

Однако число в графе загрузки CPU — это не число выдержанных сроков воспроизведения. Насколько занят весь CPU на некотором интервале времени и успела ли короткая операция пополнения выполниться в нужный момент — это разные вещи. Низкая общая нагрузка не гарантирует, что обработка звука каждый раз сразу получает свою очередь.4

В примере выше: даже если запас есть большую часть секунды, одного-единственного интервала, когда пополнение не удаётся 12 миллисекунд, хватает, чтобы исчерпать оставшиеся 10 миллисекунд звука. Запас, оставшийся позже, это одно опоздание уже не спасёт.

Дело не в медленных вычислениях, а в ожидании возможности выполниться

Например, код, готовящий аудиоданные, ждёт завершения чтения файла. Или, возможно, ждёт блокировку, которую удерживает другая часть приложения. Пока он ждёт, сам этот код почти не использует CPU. И всё же звук, который играет, продолжает расходоваться. Задержка поставки данных и ожидание потока происходят независимо от того, израсходован ли CPU.54

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

Рисунок 3: «CPU не используется» — не то же самое, что «нужная работа выполнена».

Ждать приходится и из-за устройств, на первый взгляд не связанных со звуком

Есть и второй случай: очередь не доходит на стороне Windows.

Когда приходит уведомление от сетевого устройства и подобного, Windows выполняет код обработки прерывания. Первая короткая часть этой работы — это ISR, а механизм, откладывающий остальную работу, — DPC. Пока выполняется обычный DPC или ISR, на этом логическом CPU обычные потоки выполняться не могут. Обработка звука тоже подвержена этому влиянию.64

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

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

Рисунок 4: влияние оказывает не только устройство, создающее звук; обработка других устройств тоже может влиять косвенно.

Иными словами, прерывание звука — это не только «CPU слишком медленный, чтобы довести вычисление до конца». Вычисление не может начаться, нужные данные не приходят. Это время ожидания тоже отнимается у срока звука.

3. Так, может, просто накапливать побольше звука?

Если пополнение немного запаздывает, кажется разумным держать такой запас, который поглотит это опоздание. Именно эта логика и приводит к увеличению аудиобуфера.

При тех же условиях, если накапливать больше звука заранее, короткие задержки пополнения переносятся легче. Но теперь новый звук ждёт позади уже накопленного.12

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

Запас в буфере и задержка реакцииЕсли накапливать больше звука заранее, временные задержки пополнения переносятся легче, но и ожидание до воспроизведения нового звука растёт.Накопить больше звука заранееЗадержки пополнения переносятся легчеНовый звук ждёт позадиБольше задержки от действия до звука

Рисунок 5: увеличение буфера — это настройка, которая покупает запас в обмен на скорость реакции.

Настройки буфера вида «128», «256», «512» в программах для создания музыки тоже связаны с этим временем. В PCM единицу, объединяющую отсчёты всех каналов на один момент времени, называют кадром. При 48 кГц 480 кадров — это 480 делить на 48000 секунды, то есть 10 миллисекунд звука. При той же частоте дискретизации, чем больше кадров, тем длиннее укладывающийся в них отрезок звука.3

Здесь посчитана длина звука, которую представляет этот буфер. На практике есть ещё обработка в приложении, драйвере и устройстве, поэтому это следует рассматривать отдельно от общей задержки от нажатия клавиши до слышимого звука. Кроме того, не все приложения в Windows имеют общую настройку буфера, а доступные размеры зависят от устройства и драйвера.2

Поэтому «чем меньше, тем производительнее» — неверно, но и «чем больше, тем правильнее» — тоже. Настройка состоит в том, чтобы сохранить нужную скорость реакции и при этом взять запас, при котором звук не прерывается.

4. Звуку важнее уложиться в срок, чем средняя скорость

Вернёмся к исходному вопросу.

Звук прерывается при низкой загрузке CPU потому, что наличие запаса в общей вычислительной мощности и своевременная доставка следующей порции звука — разные вещи.

Звук воспроизводится из небольшого заранее накопленного запаса. Этот запас пополняют прежде, чем он исчерпан. Даже одного опоздания с пополнением может хватить для разрыва, а увеличение запаса добавляет свободы, но удлиняет время до того, как услышишь новый звук.

Это и есть суть механизма. Вопрос при расследовании тоже меняется: вместо «сколько процентов показывал CPU» — «чего ждала следующая порция звука в момент разрыва». Дальше идёт часть про расследование, чтобы сузить конкретный симптом.

5. Расследование: сначала выясните, при каком сочетании звук прерывается

Один услышанный щелчок ещё не доказывает, что это тот самый аудио-underrun. Сам источник звука, обработка в приложении, звуковые эффекты, устройство вывода — другие проблемы дают похожий симптом. В материалах 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 может содержать имена процессов, пути к файлам и другое, поэтому следуйте правилам вашей организации и передавайте запись только тем, кому она нужна. Для записи могут требоваться права или дополнительные инструменты; на корпоративном ПК обратитесь к администратору. Поскольку сама нагрузка от записи может изменить симптом, отмечайте, велась ли она. Короткая запись, соответствующая цели, предпочтительнее долгой со всеми провайдерами. В записи, где появились предупреждения о потерянных событиях, не считайте невидимые участки нормальными.10

Важнее не рейтинг больших значений, а то, что происходило в тот же момент

В WPA увеличьте область до и после прерывания, опираясь на события звука, которые удалось захватить, и на отмеченное время. В том же диапазоне времени проверьте DPC/ISR и CPU Usage (Precise), показывающий выполнение и ожидание потоков. Если этих данных нет, проверьте, захватывает ли нужные события выбранный профиль, и запишите заново. Отсутствие записи и отсутствие проблемы — разные вещи.49

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

Разобраться, как поток ждал на участке прерыванияДля аудиопотока на рассматриваемом участке разделить ожидание в готовом к выполнению состоянии и ожидание данных и подобного и сопоставить соответствующие записи.Тот же участок вокруг прерыванияГотов к выполнению, но ждёт очередиЖдёт данные и подобноеСопоставить работу на том же CPUПроследить, что сняло ожидание

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

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

Кроме того, нельзя провести общую границу вида «если DPC короче стольких-то микросекунд, звук не прервётся ни на одном ПК». Предупредительные пороги в документации обусловлены той оценкой. Не используйте их как критерий «прошло или нет» в отрыве от фактического срока пополнения и запаса в буфере.5

7. Для разработчиков: не вносите длительные ожидания в код, который передаёт звук

Если вы сами пишете аудиоприложение, отправная точка та же. Код, заполняющий следующий буфер, должен укладываться в срок каждый раз.

В WASAPI есть способ получать событием момент, когда буфер можно обработать. А MMCSS позволяет легче выделять процессорное время потокам мультимедийной обработки с жёсткими сроками. Но это не волшебство, устраняющее ожидания. 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 с выполнением потоков, анализ CPU в WPA. ↩ ↩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. Пункт More Options в WPR и встроенные профили, такие как 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 пополнение может не уложиться в срок, если обработка звука не смогла выполниться в этот момент или ждала нужные данные. Не всякое прерывание звука вызвано этой причиной, поэтому нужны и сравнения с изменением устройства вывода и приложения.
Поможет ли увеличение аудиобуфера избавиться от прерываний звука?
Если пополнение запаздывает временно, большой буфер может поглотить это опоздание. Однако растёт и ожидание до воспроизведения накопленного звука. Это не настройка, которая устраняет постоянную нехватку вычислительной мощности или отключение устройства. В приложениях и драйверах, где размер можно изменить, запишите исходное значение и сравнивайте по одной ступени.
Сколько миллисекунд звука составляют 480 кадров при 48 кГц?
480 делить на 48000 секунды, то есть 10 миллисекунд. Один кадр PCM — это единица, объединяющая отсчёты всех каналов на один момент времени. Это значение — длина звука, которую представляет такое число кадров, а не общая задержка с учётом устройства и приложения.
Виноват ли в прерываниях звука драйвер с длительным временем выполнения DPC или ISR?
Это возможный кандидат, но по одному лишь рейтингу времени выполнения этого не установить. Сопоставьте участок, на котором произошло прерывание, ожидания аудиопотока и выполнение DPC/ISR на том же CPU. Не делайте вывода о неисправности конкретного устройства или драйвера только по имени модуля и проверяйте результаты изменения условий воспроизведения.
Поможет ли перевод плеера в приоритет реального времени?
Как общая рекомендация — нет. Повышение приоритета обычного потока не позволяет обогнать обычные DPC и ISR на том же CPU и не устраняет ожидание данных или блокировок. Разработчикам стоит использовать механизмы вроде MMCSS вместе с проектированием, которое не вносит ожиданий в путь звука, а пользователям — сначала сравнить условия воспроизведения и пути вывода.

Об авторе

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

Го Комура

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

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.

Связаться с нами

Публичные ссылки

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal
Вернуться в блог