Чаму гук перарываецца, хоць загрузка CPU нізкая? — Разбіраемся праз буфер і крайні тэрмін

Вы слухаеце музыку, і часам гук перарываецца з кароткім «пстрык». Дыспетчар задач паказвае загрузку CPU каля 10%, а нестабільны толькі гук. Чаму ж у такіх выпадках гук перарываецца, хоць у CPU ёсць запас?

Нават пры нізкай загрузцы CPU гук можа перарвацца, калі наступная порцыя аўдыяданых не паспявае да крайняга тэрміну папаўнення. Справа ў тым, што наступныя даныя трэба перадаць, пакуль прайграецца гук, які яшчэ застаецца ў буферы. Папаўненне можа спазніцца з-за чакання даных або блакіровак, з-за DPC/ISR на патрэбным лагічным CPU і г. д., і гэта здараецца, нават калі 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 выконваюцца раней за звычайныя патокі на тым жа лагічным 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["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 адкрыйце «Settings» → «System» → «Sound», выберыце патрэбны вывад і, калі ў вашым асяроддзі гэта даступна, выключыце «Audio enhancements». Калі выгляд экрана або наяўнасць пунктаў адрозніваюцца, звярніцеся да інструкцый для вашай версіі і прылады. 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 і іншае на адпаведным лагічным CPU. У другім па сабраных падзеях і стэках прасачыце, што зняло чаканне. Паколькі паток, які выконваецца, таксама можа быць спынены перапыненнем, не абмяжоўвайцеся часам у стане Ready, а накладайце на яго і ўчасткі DPC/ISR. CPU Analysis

4. Запішыце разам адпаведнасць у часе з перарывам гуку, задзейнічаныя CPU і вынікі са змененымі ўмовамі.

   Не лічыце пэўную прыладу або драйвер прычынай толькі па назве модуля з доўгім 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. Лагічныя CPU, станы патокаў 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, тэхнічнымі кансультацыямі і расследаваннем дэфектаў; асабліва моцны ў праектах з наяўнымі распрацоўкамі і ў пошуку прычын збояў, якія цяжка выявіць.