Чому звук обривається, хоча завантаження 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

Часове обмеження, за яким наступні потрібні дані треба доставити до того, як закінчаться дані, що відтворюються, тут називаємо крайнім терміном поповнення. Для обробки звуку потрібно, щоб усе було «готове до моменту, коли воно має зазвучати». Того, що «зрештою все обчислилося», недостатньо. Стан, коли постачання не встигає і дані для відтворення закінчуються, називають underrun; він призводить до обривів звуку або клацань. Навіть якщо дані надійдуть пізніше, обрив, який уже прозвучав, заповнити заднім числом неможливо. 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 загалом є запас, постачання може запізнитися, якщо ці обробки на процесорі, потрібному для звуку, затягуються або часто повторюються. У матеріалі 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

480 кадрів звуку за 48 кГц

Кадр 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 на тому самому процесорі, а якщо чекав на дані тощо, простежують обробку, яка завершила очікування.
    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 і архітектура, завдяки якій дані надходять вчасно, — різні завдання.

Принцип проєктування — відокремити обробку, яка читає з файлів чи мережі, від обробки, яка передає звук. Підготовку, тривалість якої важко передбачити, виконуйте заздалегідь, а для передавання використовуйте попередньо виділений буфер. На боці звуку зробіть так, щоб не доводилося чекати на відповідь інтерфейсу користувача, тривалі блокування чи синхронний запис у журнал.

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 на тому самому процесорі, очікування даних і блокувань залишається, а ще є ризик завадити іншим важливим процесам.
    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 на тому самому процесорі. Не робіть висновку про несправність конкретного пристрою чи драйвера лише за назвою модуля й перевірте також результати зі зміненими умовами повторення збою.

Чи допоможе встановити програвачу пріоритет реального часу?

Як загальне правило ми цього не рекомендуємо. Навіть із вищим пріоритетом звичайний потік не випередить звичайні DPC та ISR на тому самому процесорі, і очікування даних чи блокувань теж не зникне. Розробники використовують механізми на кшталт MMCSS і архітектуру, що не вносить очікувань; користувачі спершу порівнюють умови повторення збою та шлях виведення.

Профіль автора

Сторінка з профілем автора статті.

Ґо Комура

Представник компанії KomuraSoft LLC

Працює переважно над розробкою ПЗ для Windows, технічними консультаціями та розслідуванням дефектів. Особливо сильна сторона — проєкти з наявними активами та розслідування збоїв з неочевидною причиною.