Miks heli katkeb, kuigi CPU kasutus on madal? – Puhvrite ja tähtaegade vaatenurgast
· Uuendatud: · Go Komura · Windows, Heli, Jõudlus, Tõrkeotsing
Kuulate muusikat ja aeg-ajalt katkeb heli „plõksuga“. Tegumihalduri järgi on CPU kasutus umbes 10%, kuid ainult heli ei püsi stabiilsena. Miks heli sellises olukorras katkeb, kuigi protsessoril on vaba võimsust?
Isegi kui CPU kasutus on madal, võib heli katkeda, kui järgmiste heliandmete täiendamine ei jõua tähtajaks valmis. Põhjus on selles, et järgmised andmed tuleb üle anda ajal, mil puhvrisse jäänud heli veel mängib. Andmete või lukkude ootamisest, vajaliku loogilise protsessori DPC/ISR-ist jms tingitud täiendamise hilinemine tekib ka siis, kui kogu protsessori võimsust ära ei kasutata. Exclusive-Mode Streams, CPU Analysis
Samas ei saa ainuüksi kuuldud „plõksu“ põhjal kindlalt väita, et tegu on alatäitumisega (underrun). Sarnaseid sümptomeid tekitavad ka heliallikas, rakendus, heliefektid, väljundseade jms. Kõigepealt võrdleme sama heliallikaga, muutes tingimusi ükshaaval ja taastades need siis algseks; kui see ei aita põhjust kitsendada, salvestame, mis toimub enne ja pärast heli katkemist. Fix distorted or crackling audio in Windows
Selles artiklis käsitleme seda küsimust ja sellele järgnevaid küsimusi „kas piisab puhvri suurendamisest?“ ning „mida võrrelda ja mida salvestada, et põhjust kitsendada?“. Artikkel ei tee üksikute rikete põhjust kindlaks ainult CPU kasutuse või kuuldud heli põhjal.
Käsitleme peamiselt heliväljundit Windows 11-s. Võrdleme sisseehitatud, juhtmega, USB-, Bluetoothi ja muid väljundeid; muusikatootmistarkvara (DAW) puhul käsitleme ka võrdlusi juhtudel, kui rakendus või draiver pakub puhvri sätteid. Kogu salvestusahela disaini ega iga seadme traadita side diagnostikat me ammendavalt ei käsitle.
Selgituses kasutame põhinäitena jagatud režiimi. Tegelik teekond, puhvri maht ja töötlustsükkel sõltuvad rakendusest, API-st, draiverist ja seadmest ning kõigile rakendustele ühist puhvri seadistuskuva ei ole olemas. Low Latency Audio
Siin toodud CPU kasutus, 10 millisekundi jääk, täiendamise ajahetked jms on selgitamiseks tehtud oletused. Need ei ole aruanne konkreetses arvutis mõõdetud probleemi kordumise või paranemise kohta. Artikli teise poole toimingud on kontrollisammud, mida teete oma keskkonnas.
Mehhanismi saate lugeda järjest, alustades järgmisest jaotisest „Heli taasesituspuhver“. Heli katkemise uurimise toimingud on jaotistes „Kordumistingimuste võrdlemine“ ja „Heli katkemise salvestamine WPR-iga“.
Diagrammil tähistab pidev joon seost, mis kehtib alati, ja katkendjoon tingimuslikku seost (tingimused on igal seosel toodud üksikasjalikul lehel). Seoste täielik loend (5 kokku, koos tõendite ja kindlusastmega) ning põhimõistete definitsioonid on koondatud teadmuskaardi üksikasjalikule lehele (jaapani keeles). Andmed: JSON-LD / Turtle
Heli taasesituspuhver
Ainult muusikafaili salvestamisest ei piisa, et kõlarid hakkaksid mängima. Rakendus valmistab heliandmed ette ja toimetab need Windowsi ja draiveri kaudu väljundseadmesse. Heli taasesituspuhver on ala, kuhu kogutakse ajutiselt andmed, mis esitatakse järgmisena. Sel ajal kui seade esitab praeguseid andmeid, valmistab andmeid pakkuv pool ette järgmised andmed ja täiendab nendega puhvrit. Rendering a Stream
flowchart TB
accTitle: Heli kogutakse veidi ette ja esitatakse siis
accDescr: Ettevalmistatud heliandmed lisatakse puhvrisse ja järgmised andmed valmistatakse ette sel ajal, kui seadme poolne esitus edasi liigub.
A["Valmista järgmine heli"] --> B["Täienda puhvrit"]
B --> C["Esita kogutud heli"]
C -.->|"enne otsasaamist"| A
Joonis 1: Et esitus jätkuks, peab täiendamine pidama sammu heli kasutava poolega.
Joonis 1 on kontseptuaalne joonis, mis näitab ainult täiendamise ja tarbimise suhet. See ei käsitle tegeliku heliteekonna mitut puhvrit füüsiliselt ühe alana. Low Latency Audio
Puhvri ülesanne on neelata lühikesi ajalisi nihkeid heli ettevalmistava ja seda kasutava poole vahel ning tagada katkematu esitus. Samas on puhvri maht ja selles praegu olevate esitamata andmete hulk eri asjad. See, et „mahtu on 10 millisekundit“, ei tähenda, et alati on alles 10 millisekundi jagu andmeid. Rendering a Stream
Siin nimetame täiendamise tähtajaks ajalist piirangut, mille kohaselt vajalikud järgmised andmed tuleb kohale toimetada enne, kui esitatavad andmed otsa saavad. Helitöötluses on nõutav, et andmed „said valmis esitamise ajaks“. Ainult sellest, et „arvutus sai lõpuks tehtud“, ei piisa. Olukord, kus andmete pakkumine ei jõua õigeks ajaks ja esitatavad andmed saavad otsa, on alatäitumine, mis põhjustab heli katkemist või klõpse. Isegi kui andmed jõuavad hiljem kohale, ei saa juba kuuldud lünka tagantjärele täita. Exclusive-Mode Streams
Heliandmete teekond
Tavalises jagatud režiimis võtab taasesitusrakenduse ettevalmistatud andmed vastu Windowsi helimootor, mis segab mitu heli kokku või rakendab efekte ning annab andmed seejärel edasi draiverile ja väljundseadmele. Taasesitusrakendus osaleb nii heliallika lugemises kui ka väljundisse andmete edastamises, draiver ja väljundseade aga toimetavad andmed seadme poolele ja esitavad need. Low Latency Audio
flowchart TB
accTitle: Heliandmete teekond jagatud režiimis
accDescr: Taasesitusrakenduse ettevalmistatud andmed segab ja töötleb efektidega helimootor, mis annab need draiverile, ning väljundseade esitab need.
A["Taasesitusrakendus: valmistab andmed"] --> E["Helimootor: segamine, efektid"]
E --> D["Draiver: viib seadmesse"]
D --> O["Väljundseade: esitus"]
Joonis 2: Näide jagatud režiimist. Vahepealne töötlus ja puhvrid sõltuvad API-st ja seadmest.
Ka seadme poolel võib olla töötlust ja puhvreid, nii et kogu viivitus ei sõltu ainult rakenduse poole puhvrist. See selgitus eeldab jagatud režiimi teekonda ega tähenda, et kõik API-d läbiksid sama töötluse. Low Latency Audio
Täiendamine 10 millisekundi jäägi juures
Oletame, et puhvris on praegu alles veel 10 millisekundi jagu esitamata andmeid. Kui järgmine täiendamine toimub 8 millisekundi pärast, jätkub esitus katkematult, sest andmeid on veel alles; kui aga täiendada ei saa enne 12 millisekundi möödumist, saavad selles lihtsustatud näites andmed otsa 10 millisekundi juures.
flowchart TB
accTitle: Sama 10 millisekundi jäägi korral sõltub tulemus täiendamise ajast
accDescr: Selgitava oletusena näitab joonis, et 10 millisekundi esitusandmete jäägi korral jõuab 8 millisekundi pärast tehtav täiendamine õigeks ajaks, 12 millisekundi pärast tehtav aga alles pärast andmete otsasaamist.
A["Jääk 10 millisekundit"] --> B{"Järgmine täiendamine"}
B -->|"8 ms pärast"| C["Esitus jätkub"]
B -->|"12 ms pärast"| D["Otsas 10 ms juures"]
Joonis 3: Ajaliselt lihtsustatud näide. Oluline pole ainult see, kas täiendamine õnnestus, vaid ka see, millal see õnnestus.
CPU kasutus ja täiendamise hilinemine
CPU kasutus näitab hõivatust teatud ajavahemiku jooksul. See mõõdab teist asja kui seda, kas helitöötlus sai käivituda just sel hetkel, kui seda vaja oli. Isegi kui protsessoril on suurema osa sekundist vaba võimsust, võib heli katkeda, kui esineb üksainus 12-millisekundiline lõik, mil täiendada ei saa – sellest ühest hilinemisest piisab. Hiljem üle jääva töötlusvõimsusega ei saa möödunud esitusaega tagasi võita. CPU Analysis
flowchart TB
accTitle: Keskmine varu ja üks täiendamise hilinemine
accDescr: Isegi kui protsessoril on suurema osa sekundist vaba võimsust, võib heli katkeda, kui esineb üksainus 12-millisekundiline lõik, mil täiendada ei saa.
A["Suurema osa sekundist on CPU vaba"] --> B["Ühel korral 12 ms ilma täienduseta"]
B --> C["Sellest ühest korrast heli katkeb"]
Joonis 4: Ka keskmise varu korral ei saa möödunud esitusaega tagasi võita.
Tähtajast ei võta aega ainult arvutus. Sinna kuulub ka ootamine, kuni töötlus saab alata, ja ootamine, kuni vajalikud andmed kohale jõuavad. Seetõttu muudame ka uurimise küsimust: mitte ainult „mitu protsenti oli CPU kasutus?“, vaid „mida järgmine heli ootas sel hetkel, kui heli katkes?“.
Andmete ja lukkude ootamine
Oletame, et heliandmeid ettevalmistav töötlus ootab faili lugemise lõpetamist. Sama kehtib juhul, kui see ootab lukku, mida hoiab rakenduse mõni teine töötlus. Ootav töötlus ise kasutab protsessorit vähe, kuid seadme poolel esitus jätkub ja allesjäänud heli hulk väheneb. Results for the Streaming Media Performance Assessment, CPU Analysis
flowchart TB
accTitle: Esitus liigub edasi ka ooteajal, mil CPU-d ei kasutata
accDescr: Kui helitöötlus ootab andmeid või lukku, ei kasuta see töötlus protsessorit, kuid esitus liigub edasi ja jääk väheneb; kui täiendamine hilineb, võib puhver tühjaks saada.
A["Helitöötlus ootab andmeid"] --> B["See töötlus ei kasuta CPU-d"]
B --> C["Esitus jätkub ka sel ajal"]
C --> D["Hilinenud täiendusel saab varu otsa"]
Joonis 5: See, et CPU-d ei kasutata, ei tähenda, et vajalik töö on tehtud.
DPC, ISR ja helilõim
ISR on töötlus, mis reageerib seadmest tulevale katkestusele. DPC on mehhanism, mis lükkab ülejäänud töö hilisemaks, et katkestuse töötlus jääks lühikeseks. Tavaline DPC täidetakse enne sama loogilise protsessori tavalisi lõimi ning sel ajal, kui tavaline DPC või ISR töötab, ei saa selle loogilise protsessori peal tavalisi lõimi täita. Introduction to DPCs, CPU Analysis
Isegi kui protsessoril tervikuna on varu, võib andmete pakkumine hilineda, kui need töötlused venivad või sagenevad protsessoril, mida helitöötlus vajab. Microsofti heli ja video jõudlusanalüüsi materjalides on heli katkemise võimalike põhjustena nimetatud ka võrgu-, salvesti-, graafika- ja muude draiverite pikki DPC/ISR-e. Alati ei piisa ainult heli väljastava seadme uurimisest. Results for the Streaming Media Performance Assessment
flowchart TB
accTitle: Kui seadmele reageerimine viivitab heli täitmist
accDescr: Kui tavalised DPC-d või ISR-id venivad helitöötluseks vajalikul protsessoril, hilineb lõime täitmine ja see võib mõjutada täiendamise tähtaega.
A["DPC/ISR samal CPU-l"] -->|"kui venib"| B["Heli täitmine peab ootama"]
B --> C["Järgmise heli täiendamine hilineb"]
C --> D["Jäägi lõppedes heli katkeb"]
Joonis 6: Ka heli väljastavast seadmest erinev töötlus võib kaudselt mõjutada heli täiendamist.
Ühist piiri stiilis „kui DPC kestab alla nii mitme mikrosekundi, ei katke heli üheski arvutis“ tõmmata ei saa. Jõudlushindamise materjalide hoiatusväärtused kehtivad selle hindamise tingimustes ning me ei kasuta neid ohutuskriteeriumina lahus tegelikust täiendamise tähtajast ja puhvri varust. Results for the Streaming Media Performance Assessment
Puhvri maht ja taasesituse viivitus
Kui samadel tingimustel kogutakse ette rohkem heli, on ajutisi täiendamise hilinemisi lihtsam neelata, kuid uus loodud heli ootab juba kogutud heli taga. Ooteaeg, mis on muusika kuulamisel vastuvõetav, muutub klahvpilli mängides või mikrofoni häält töödeldes ja seda ise kuulates häirivaks nihkeks tegevuse ja heli vahel. Exclusive-Mode Streams, Low Latency Audio
flowchart TB
accTitle: Puhvri varu ja reageerimise viivitus
accDescr: Kui ette kogutakse rohkem heli, on ajutisi täiendamise hilinemisi lihtsam neelata, kuid pikeneb ka ooteaeg, enne kui uus heli esitatakse.
A["Kogu ette rohkem heli"] --> B["Hilinemisi on lihtsam neelata"]
B -->|"vastutasuks"| C["Uus heli ootab järjekorras"]
C --> D["Tegevusest helini kulub kauem"]
Joonis 7: Puhvri suurendamine on häälestus, mis loob varu reageerimiskiiruse arvelt.
Ei kehti ei „mida väiksem, seda parem jõudlus“ ega „mida suurem, seda õigem“. Eesmärk on saavutada katkemiseta varu, säilitades samal ajal vajaliku reageerimiskiiruse.
Puhvri suurendamine loob varu ajutiste pakkumise hilinemiste jaoks. Kui keskmine pakkumine ise tarbimisega sammu ei pea, pikendab piiratud puhvri suurendamine vaid aega, kuni puhver tühjeneb, ega lahenda ka seadme ühenduse katkemist. See ei ole ka soovitus, et eksklusiivse režiimi kasutamine lahendaks kõik. Exclusive-Mode Streams
480 kaadrit heli 48 kHz juures
PCM-kaader on ühik, mis koondab kõigi kanalite samal ajahetkel esitatavad näidised. Stereo puhul ei arvutata aega kaadrite arvu kahekordistades. Kaadrite arvuga esitatud heli pikkus leitakse valemiga „kaadrite arv ÷ diskreetimissagedus“; 480 kaadrit 48 kHz juures annab 480 ÷ 48000 sekundit ehk 10 millisekundit. Kui kaadrite arvu suurendada ja jätta sageduseks 48 kHz, pikeneb ka heli kestus, mida saab ette koguda. Rendering a Stream
| Kaadrite arv | Heli pikkus 48 kHz juures (arvutatud) |
|---|---|
| 128 | umbes 2,67 millisekundit |
| 256 | umbes 5,33 millisekundit |
| 480 | 10 millisekundit |
| 512 | umbes 10,67 millisekundit |
See aeg ei ole sama mis koguviivitus klahvi vajutamisest heli kuuldumiseni. Põhjus on selles, et lisandub ka rakenduse, draiveri, seadme ning muude puhvrite ja töötluse aeg. Ka DAW sätete väärtusi lugege, kontrollides ühikut ja seda, millist puhvrit väärtus puudutab. Low Latency Audio
flowchart TB
accTitle: Kaadrite arvust arvutatud aeg ja koguviivitus
accDescr: 480 kaadrit jagatuna 48000-ga ehk 10 millisekundit on aeg, mida puhver esindab; kui lisandub rakenduse, draiveri, seadme jm töötlus, saadakse koguviivitus klahvist helini.
A["480 ÷ 48000"] --> B["Puhvrile vastav 10 ms"]
B -->|"lisandub muu töötlus"| C["Koguviivitus klahvist helini"]
Joonis 8: Kaadrite arvust arvutatud aeg on vaid osa koguviivitusest.
Kordumistingimuste võrdlemine
Kõigepealt kitsendame kombinatsiooni, milles probleem kordub, ja liigume üksikasjaliku salvestamise juurde ainult siis, kui see on vajalik. Allpool on protseduur põhjuse kontrollimiseks, mitte abinõude loend, mille kõik sättemuudatused tuleks korraga ellu viia.
Salvestage oma töö, lõpetage päris koosolekud ja salvestused ning proovige seejärel kõrvu säästva helitugevusega. Pange kirja algne väljund, helitäiustuste olek, puhvri väärtused jms, et saaksite kõik tagasi muuta. Jätke vahele punktid, mille sätet ei pakuta, ja ärge muutke sätete nähtavale toomiseks registrit ega muud sarnast.
-
Valige sama lühike heliallikas ja vaatlusaeg ning kontrollige, kas probleem kordub algsetes tingimustes.
Pange kirja Windowsi versioon, rakenduse nimi ja versioon, väljundseade, ühendusviis ja draiveri versioon. Märkige üles ka heli katkemise aeg, sel hetkel tehtud toiming ja katkemiste arv. Kui probleem algsetes tingimustes ei kordu, ärge järeldage, et olukord on paranenud, vaid minge tagasi ja tehke kindlaks tingimused, milles probleem kordub.
-
Valige allolevast tabelist üks võrdlus ja esitage heli, muutes ainult seda tingimust.
Võrreldav tingimus Mida uurida Kohalikult salvestatud heliallikas vs. esitus võrgu kaudu Kas probleem tekib ainult võrgu kaudu? Kui sisu on sama, kuid vorming või töötlemise teekond erineb, pange ka see kirja. Sama heliallika esitamine teises rakenduses Kas probleem piirdub kindla rakendusega? Bluetoothi vm väljund vs. sisseehitatud või juhtmega väljund Kas probleem piirdub kindla väljunditeega? Helitäiustused sees või väljas Kas tulemus muutub koos efektitöötlusega? DAW vm praegune puhver vs. ühe astme võrra suurem väärtus Kas tulemus muutub, kui ette kogumise varu suurendada? Kas ka viivitus tegevusest helini on vastuvõetav? -
Kui võrdlete helitäiustusi, lülitage säte vastava väljundi jaoks ajutiselt välja.
Valige Windowsi jaotises „Sätted“ → „Süsteem“ → „Heli“ vastav väljund ja lülitage keskkondades, kus see on saadaval, välja „Helitäiustused“. Kui kuva või sätete olemasolu erineb, vaadake selle versiooni või seadme juhiseid. Fix distorted or crackling audio in Windows
-
Taastage muudetud säte algseks ja proovige uuesti sama heliallika ja vaatlusajaga.
Pange kõrvuti tulemused tingimustes „algne“, „üks muudetud“ ja „algseks taastatud“. Kui muudatusel mõju ei olnud, taastage algne olek ja alles siis liikuge järgmise võrdluse juurde. Kui sätete kombinatsioone järjest muuta, ei saa enam aru, mis mõjus.
-
Kui proovite draiverit vahetada, tehke seda alles pärast ametliku levitusallika ja taastamisviisi kontrollimist.
Kasutage Windows Update’i või seadme tootja ametlikku levitust ning pange kirja versioonid ja sätted enne ja pärast muudatust. Kontrollige eelnevalt, kas muudatuse saab tagasi võtta, ning hallatavas arvutis pidage nõu administraatoriga. Ärge pidage probleemi lahendatuks ainult seetõttu, et kohe pärast värskendust õnnestus üks kord heli esitada, vaid kontrollige samades kordumistingimustes. Fix distorted or crackling audio in Windows
Soovitud tulemus on kirje, mis seob sümptomi tingimustega, näiteks „probleem kordub selle rakenduse ja selle väljundi kasutamisel“. Ka siis, kui leiate sätte, mis olukorda parandab, hoidke see põhjuse kindlakstegemisest lahus.
flowchart TB
accTitle: Võrdlus, kus muudetakse üht tingimust ja see taastatakse
accDescr: Kontrollitakse probleemi kordumist sama heliallikaga, muudetakse üht tingimust, näiteks rakendust või väljundit, ja pannakse kirja ka tulemus pärast algse oleku taastamist.
A["Esita algses kombinatsioonis"] --> B["Muuda üht tingimust ja esita"]
B --> C["Taasta ja esita"]
C --> D["Pane kirja katkemise tingimus ja aeg"]
Joonis 9: Ühekordsest paranemisest olulisem on kontrollida, et tingimus ja sümptom vastavad teineteisele korduvalt.
Kordumine enne ja pärast tingimuse muutmist
„Sümptomit õnnestus leevendada“, „tingimusi õnnestus kitsendada“ ja „algpõhjus tehti kindlaks“ on eri tasemel tulemused. Pange järeldus kirja vastavalt sellele, mida õnnestus tegelikult vaadelda.
| Vaadeldud tulemus | Otsus ja järgmine samm |
|---|---|
| Probleem kordub algsetes tingimustes, muutmisel olukord paraneb ja taastamisel probleem kordub | Vihje, mis viitab seosele selle tingimusega. Kontrollige korduvalt sama vaatlusajaga ning hoidke ajutine lahendus ja põhjuse kindlakstegemine lahus. |
| Puhvri suurendamine parandab olukorda | Võimalik, et mõju avaldas ajavaru. Kontrollige ka kasutusotstarbeks vajalikku reageerimiskiirust ja ärge järeldage sellest veel konkreetse draiveri viga. |
| Sisseehitatud või juhtmega väljundiga probleem ei kordu | Vihje väljunditee uurimiseks. Kuna muutuvad ka draiver ja puhver, ärge järeldage, et põhjus on ainult raadiolainetes. |
| Probleem ei kordu ka algsetes tingimustes või tulemus muutub iga katsega | Ainult selle võrdluse põhjal ärge hinnake olukorda paranenuks. Vaadake üle kordumistingimused ja vaatlusaeg ning vajaduse korral minge edasi salvestamise juurde. |
| Salvestisest puuduvad vajalikud sündmused või on sündmusi kaotsi läinud | Ärge käsitlege seda tõendina, et probleemi ei olnud. Kontrollige profiili ja salvestustingimusi ning salvestage uuesti. |
flowchart TB
accTitle: Kolm tulemust, mis viitavad seosele tingimusega
accDescr: Kui probleem kordub algsetes tingimustes, üht tingimust muutes olukord paraneb ja taastamisel probleem kordub, on see vihje seosele selle tingimusega, kuid seda hoitakse lahus põhjuse kindlakstegemisest.
A["Kordub algsetes tingimustes"] --> B["Ühe muutmisel paraneb"]
B --> C["Taastamisel kordub"]
C --> D["Vihje seosele selle tingimusega"]
Joonis 10: Ka siis, kui kõik kolm on täidetud, saab teada ainult vihje seosele.
Madal CPU kasutus ei tõenda, et heli tähtajast peeti kinni. Samas ei saa ainuüksi heli katkemise põhjal öelda, et algpõhjus oli täiendamise hilinemine. Võrrelge heliallikat, rakenduse töötlust, efekte, väljunditeed jms ning tehke otsus vaadeldu piires. Fix distorted or crackling audio in Windows
Ajutise lahenduse kasutuselevõtul pange kirja algne säte, tehtud muudatus, vaatlusaeg, kas probleem kordus ja milline viivitus on vastuvõetav. Kui algpõhjus on veel kindlaks tegemata, märkige ka see üles.
Heli katkemise salvestamine WPR-iga
Seda tehakse siis, kui ainult tingimuste võrdlemisega ei õnnestu põhjust kitsendada, või siis, kui soovite uurida draiveri poolset töötlust. WPR on salvestamise ja WPA salvestatud ajatelje analüüsimise tööriist. Valmistage ette Windows Performance Toolkit, salvestamiseks vajalikud õigused ja ETL-faili salvestuskoht. Kui hallatavasse arvutisse on vaja tööriist paigaldada ja sellega salvestada, paluge seda administraatorilt. Kuvatavad nimed ja saadaolevad profiilid kontrollige paigaldatud versioonis. Windows Performance Recorder
ETL-fail võib sisaldada protsesside nimesid, failiteid jms. Enne salvestamist kontrollige ettevõtte reegleid ja seda, kellega faili jagate, ning ärge lisage seda muutmata kujul avalikku kohta. Kui töötab mõni teine salvestusseanss, ärge peatage seda omal käel, vaid küsige vastutavalt isikult. WPR How-to Topics
-
Avage WPR-is „More Options“ ja valige eesmärgile vastav salvestusprofiil.
Standardprofiilide hulgas on „Audio glitches“ ja „CPU usage“. Valige seadistus, millega saab uurida heli katkendlikkust ja protsessori tegevust. Kontrollige saadaolevaid profiile, kuvatavaid nimesid ja kogutavaid andmeid paigaldatud versioonis ning ärge seadistage kõigi tüüpide pikaajalist salvestamist. Built-in Recording Profiles
-
Alustage salvestamist enne, kui heli katkemise esile kutsute.
Kui ilmub kinnitusküsimus olemasoleva salvestuse peatamise kohta, ärge jätkake, vaid loobuge alustamisest ja küsige vastutavalt isikult. Hoidke tingimused samad kui salvestamiseta katsetes ja arvestage ka võimalusega, et salvestamise enda koormus muudab sümptomeid. WPR How-to Topics
-
Esitage heli võrdlemisel leitud tingimustes ning pange kirja katkemise aeg ja toiming.
Kaasake ka veidi probleemivaba lõiku enne ja pärast sümptomit. Kui probleem salvestamise ajal ei kordunud, märkige see salvestise juurde selgelt ning ärge käsitlege seda salvestisena, mis tabas põhjuse.
-
Kui probleem on kordunud, lõpetage salvestamine nupuga „Save“ ja salvestage ETL-fail.
Nupuga „Cancel“ salvestist ei salvestata. Pange kirja salvestuskoht, kordumistingimused, kas salvestis on olemas ja kas ilmus hoiatus sündmuste kaotsimineku kohta. Kui salvestises on lünki, ärge hinnake nähtamatut lõiku normaalseks. WPR How-to Topics
Kui teil on olemas ETL-fail ja märkmed heli katkemise aja, toimingu ja tingimuste kohta, olete valmis WPA-s võrdlema. Ainuüksi see, et salvestis on talletatud, ei tähenda veel, et vajalikud sündmused said kogutud. Sisu kontrollime järgmises jaotises „Täitmine ja ootamine enne ja pärast heli katkemist“.
flowchart TB
accTitle: Lühikese salvestise tegemine, mis sisaldab heli katkemist
accDescr: Alusta WPR-iga salvestamist, kutsu sümptom esile ja pane aeg kirja, peata salvestamine ja uuri salvestatud faili WPA-s.
A["Alusta WPR-iga salvestamist"] --> B["Kutsu samades tingimustes katkemine esile"]
B --> C["Märgi aeg ja toiming, salvesta"]
C --> D["Suurenda WPA-s ümbritsevat lõiku"]
Joonis 11: Pärast sümptomi möödumist vaadatud CPU kasutusest ei piisa; vaja on salvestist lõigust, kus sümptom tekkis.
Täitmine ja ootamine enne ja pärast heli katkemist
Võtke valmis salvestatud ETL-fail ja märkmed probleemi kordumise aja kohta. Järgnev on WPA-s uurimise lähtepunkt. Kui vaja on üksikasjalikku analüüsi koos kutsepinude ja sümbolitega, paluge seda administraatorilt või arendajalt, käsitsedes salvestist hoolikalt.
-
Avage ETL-fail WPA-s ja suurendage kogutud helisündmuste ja kordumisaja põhjal heli katkemise ümbrust.
Jätke võrdluseks alles ka lõik, kus sümptomit ei olnud. Ärge vaadake ainult maksimumväärtuste pingerida, vaid võrrelge sama ajavahemiku piires.
-
Vaadake samas vahemikus üle „DPC/ISR“ ja „CPU Usage (Precise)“.
Kui vajalikke andmeid ei ole, kontrollige, kas profiil suudab neid koguda, ja minge tagasi WPR-iga salvestamise juurde. See, et andmeid ei salvestatud, ja see, et probleemi ei olnud, on eri asjad. CPU Analysis, Built-in Recording Profiles
-
Eristage, kas heliga seotud lõim oli täitmisvalmis, kuid ootas järjekorras, või ootas see andmeid vms.
Esimesel juhul kontrollige, kas asjaomasel loogilisel protsessoril ei töötanud kaua DPC/ISR vms. Teisel juhul jälgige kogutud sündmuste ja kutsepinude abil, mis ootamise lõpetas. Kuna katkestus võib peatada ka täitmisel oleva lõime, ärge piirduge ainult Ready-ajaga, vaid asetage peale ka DPC/ISR-i lõigud. CPU Analysis
-
Pange koos kirja ajaline vastavus heli katkemisega, asjaomased protsessorid ja tingimuste muutmise tulemused.
Ärge tehke pika DPC/ISR-i mooduli nime põhjal ainuüksi kindlaks, et põhjus on konkreetne seade või draiver. Võimalik, et vaatate hoopis teisel ajahetkel esinenud suurt väärtust või ühist osa, mida läbivad mitu seadet.
flowchart TB
accTitle: Ootamise viisi uurimine heli katkemise lõigus
accDescr: Suurendatakse heli katkemise ümbrust ja vaadatakse helilõime olekut. Kui lõim on täitmisvalmis ja ootab järjekorras, võrreldakse seda sama protsessori DPC-de ja ISR-idega; kui see ootab andmeid vms, jälgitakse ootamise lõpetanud töötlust.
A["Suurenda katkemise ümbrust"] --> B{"Lõime olek"}
B -->|"järjekorras"| C["DPC/ISR"]
B -->|"ootab andmeid"| D["Ootamise lõpetanud töötlus"]
Joonis 12: Ärge noppige välja ainult maksimumväärtusi, vaid lugege neid koos lõiguga, kus helitöötlust vajati.
Kui põhjust kindlaks teha ei õnnestu, andke uurimine edasi lõpetamatuna. Lisage OS-i, rakenduse, seadme ja draiveri versioonid, kordamise sammud, tulemused enne ja pärast muudatust, tekkimise aeg, kasutatud kogumisprofiil ja see, kas ilmus kaotsimineku hoiatus. Jagage ETL-faili ettevõtte reeglite kohaselt ainult nendega, kes uurimise eest vastutavad.
Helirakenduse eellaadimine
Kui loote ise helirakendust, kavandage see nii, et järgmist puhvrit täitev töötlus jõuaks iga kord tähtajaks valmis. WASAPI-s on võimalik saada sündmusena teade, millal puhvrit saab töödelda. Exclusive-Mode Streams
MMCSS on mehhanism, mis jaotab protsessori ressursse ajakriitilise multimeediatöötluse lõimedele. Sellel ei ole funktsiooni, mis valmistaks andmed kettalt ette või kõrvaldaks luku ootamise. Ka MMCSS-i jaotust kasutades on eraldi vaja disaini, mis valmistab andmed ette ja vähendab ootamist. Multimedia Class Scheduler Service
flowchart TB
accTitle: MMCSS-i vastutusala
accDescr: MMCSS jaotab protsessori ressursse ajakriitilise töötluse lõimedele, kuid andmete ettevalmistamine ja luku ootamise vähendamine tehakse eraldi disainiga.
M["MMCSS: jaotab CPU ressursse"] -.->|"vaja eraldi"| D["Andmete ettevalmistus ja ootamise vähendamine"]
Joonis 13: Protsessori ressursside jaotamine ja disain, mis toob andmed õigeks ajaks kohale, on eri ülesanded.
Disaini põhimõte on eraldada failist või võrgust lugemine ja heli edasiandmine. Ettevalmistus, mille kestust on raske ette näha, tehakse varakult ja üleandmiseks kasutatakse eelnevalt eraldatud puhvrit. Helipoolne osa ehitatakse nii, et see ei pea ootama kasutajaliidese vastust, pikki lukke ega sünkroonset logikirjutamist.
flowchart TB
accTitle: Raskesti ajastatava ettevalmistuse ja heli edastuse eraldamine
accDescr: Disain, kus lugemine jms tehakse ettevalmistava töötluse käigus ning ettevalmistatud andmed antakse puhvri kaudu helitöötlusele, et vähendada pikki ootamisi vahetult enne tähtaega.
A["Valmista andmed eeltöötluses"] --> B["Eelnevalt eraldatud üleandmisala"]
B --> C["Helitöötlus annab vajaliku osa"]
C --> D["Edastus heliväljundisse"]
Joonis 14: Aeganõudev töö viiakse eemale hetkest vahetult enne heli üleandmist.
Kui ettevalmistav pool seiskub pikaks ajaks, saab varu otsa ka sellise eraldamise korral. Pange helitöötlust segamata kirja mitte ainult keskmine töötlusaeg, vaid ka korrad, mil esines pikk töötlus või ootamine, ning see, mitu korda andmeid ei õnnestunud edastada. Kontrollige tegelikult valitud puhvri mahtu ja perioodi API-st või draiverist ning ärge eeldage, et määratud väärtus võeti kasutusele muutmata kujul. Rendering a Stream, Low Latency Audio
Nii arvnäited kui ka disaininäited on selgitamiseks; need ei ole soovitatavad sätteväärtused konkreetsele seadmele ega garantii, et heli mis tahes keskkonnas ei katke.
Reaalajaprioriteedi mõju
Me ei soovita üldiselt, et kasutaja muudaks kogu mängija prioriteediks „Reaalaeg“. On oht, et see takistab muid olulisi töötlusi, ning tavalise lõime prioriteedi tõstmine ei kõrvalda DPC/ISR-i ega andmete ja lukkude ootamist. Arenduses kasutatakse MMCSS-i ja muid mehhanisme ning disaini, mis ei too pikki ootamisi heli edastusse. Scheduling Priorities, CPU Analysis
flowchart TB
accTitle: Ootamised, mis jäävad alles ka reaalajaprioriteedi korral
accDescr: Isegi kui mängija seatakse reaalajaprioriteedile, ei saa tavaline lõim mööduda sama protsessori DPC-dest ega ISR-idest, alles jääb ka andmete ja lukkude ootamine ning on oht takistada muid olulisi töötlusi.
A["Mängija reaalajaprioriteedile"] --> B["DPC/ISR-ist ei saa mööduda"]
B --> C["Andmete ja lukkude ootamine jääb"]
C --> D["Oht takistada muid töötlusi"]
Joonis 15: Ka prioriteedi tõstmisel jäävad alles ootamised, mis viivitavad heli täiendamist.
Seotud artiklid
- Windowsi „Protsessori ajastamine“ ja taustateenuste säte
- Windowsi 100% kettakasutuse põhjuse ohutu piiritlemine
- Miks RDP on aeglane, kuigi ühendus on kiire?
Viited
- Microsoft Learn, Rendering a Stream. Taasesituspuhvri täiendamine, jääk, tegelik puhvri suurus ja PCM-kaadri definitsioon.
- Microsoft Learn, Exclusive-Mode Streams. Puhvri täiendamise ajastus ja helitõrked, tasakaal viivitusega ning sündmuspõhine täiendamine. Viide ei tähenda, et eksklusiivset režiimi ennast üldiselt soovitataks.
- Microsoft Learn, Low Latency Audio. Windowsi heliteekond, puhvrid, seadmed, efektitöötlus ja viivitus ning madala latentsuse kompromissid.
- Microsoft Learn, CPU Analysis. Loogilised protsessorid, lõimede olekud Ready/Waiting, DPC/ISR-i ja lõimede täitmise seos ning WPA protsessorianalüüs.
- Microsoft Learn, Introduction to DPCs. Mehhanism, mis hoiab katkestuse töötluse lühikese ja lükkab ülejäänud töö DPC-le.
- Microsoft Learn, Results for the Streaming Media Performance Assessment. Pikad ja sagedased DPC/ISR-id, ebapiisav andmete pakkumine ja helitõrked. Hindamise hoiatusväärtusi ei üldistata kõigi seadmete ohutuskriteeriumiks.
- Microsoft Support, Fix distorted or crackling audio in Windows. Helitäiustuste, vormingu, draiverite jms kontrollimine.
- Microsoft Learn, Windows Performance Recorder. ETW-salvestus ja analüüs WPA-ga, Windows Performance Toolkiti kasutamine.
- Microsoft Learn, Built-in Recording Profiles. WPR-i More Options ning standardprofiilid, näiteks Audio glitches ja CPU usage.
- Microsoft Learn, WPR How-to Topics. Salvestamise alustamine ja talletamine nupuga Save, konfliktid olemasolevate seanssidega ning ettevaatus isikuandmete ja sündmuste kaotsimineku osas.
- Microsoft Learn, Multimedia Class Scheduler Service. Protsessori ressursside jaotamine ajakriitilisele multimeediatöötlusele.
- Microsoft Learn, Scheduling Priorities. Protsesside ja lõimede prioriteedid ning hoiatused reaalajaprioriteedi kohta.
Seotud artiklid
Viimased samade siltidega artiklid. Nende abil saate teemasse süveneda.
Tehnikablogi avamise teade – Windowsi / C# / COM arendusblogi
KomuraSoft LLC tehnikablogi avamise teade. Jagame teadmisi Windowsi arendusest, C# / .NET-ist, COM-ist, disainist ja arendustööriistadest.
Seotud teemad
Sellega lähedased teemalehed. Artiklist saate liikuda edasi seotud teenuste ja teiste artiklite juurde.
Windowsi tehnilised teemad
Koondleht Windowsi arenduse, veaotsingu ja olemasolevate lahenduste taaskasutuse tehnilistest teemadest.
Teenused, millega see teema seondub
See artikkel seondub järgmiste teenuslehtedega. Alustage sobivaimast.
Windowsi rakenduste arendus
Toetame ärirakenduste, seadmete integreerimise, sidevahendite jms Windowsi tarkvara arendust.
Korduma kippuvad küsimused
Küsimused, mida nõustamisel selle artikli teemal sageli esitatakse.
- Miks heli katkeb, kuigi CPU kasutus on vaid umbes 10%?
- Helil on tähtaeg: järgmised andmed tuleb lisada enne, kui parajasti esitatavad andmed otsa saavad. Isegi kui kogu CPU kasutus on madal, ei pruugi täiendamine õigeks ajaks valmis jõuda, kui helitöötlus ei saanud just sel hetkel käivituda või ootas vajalikke andmeid. Kõik heli katkemised ei pruugi sellest põhjusest tuleneda ning vaja on ka võrdlusi, kus muudetakse väljundseadet või rakendust.
- Kas suurem helipuhver kõrvaldab heli katkemise?
- Kui täiendamine hilineb ajutiselt, võib suur puhver selle mõnikord neelata. Samas pikeneb ka ooteaeg, enne kui kogutud heli esitatakse. See ei ole säte, mis kõrvaldaks töötlusvõimsuse püsiva puudujäägi või seadme ühenduse katkemise. Rakendustes ja draiverites, kus väärtust saab muuta, pange algne väärtus kirja ja võrrelge ühe astme kaupa.
- Mitu millisekundit heli on 480 kaadrit 48 kHz juures?
- 480 ÷ 48000 sekundit ehk 10 millisekundit. PCM-i üks kaader on ühik, mis koondab kõigi kanalite sama ajahetke näidised. See väärtus on selle kaadrite arvuga esitatud heli pikkus, mitte koguviivitus koos seadme ja rakendusega.
- Kas pika DPC või ISR täitmisajaga draiver on heli katkemise süüdlane?
- See on üks kandidaat, kuid ainuüksi täitmisaegade pingerea põhjal ei saa seda kindlaks teha. Võrrelge heli katkemise lõiku helilõime ootamise ja sama protsessori DPC/ISR-i täitmisega. Ärge järeldage ainult mooduli nime põhjal konkreetse seadme või draiveri viga ning kontrollige ka tulemusi, mis saadi kordumistingimusi muutes.
- Kas mängija seadmine reaalajaprioriteedile parandab olukorda?
- Me ei soovita seda üldiselt. Tavalise lõime prioriteedi tõstmine ei lase tal mööduda sama protsessori tavalistest DPC-dest ega ISR-idest ning ei kõrvalda ka andmete ega lukkude ootamist. Arendajad kasutavad MMCSS-i ja muid mehhanisme ning disaini, mis ei too ootamist heli edastusse; kasutajad võrdlevad esmalt kordumistingimusi ja väljunditeed.
Autori profiil
Artikli autori profiilileht.
Go Komura
KomuraSoft LLC esindaja
Tegeleb peamiselt Windowsi tarkvara arenduse, tehnilise nõustamise ja veaotsinguga. Tugevus on projektid, kus on säilinud olemasolevaid lahendusi, ning raskesti jälgitavate põhjustega tõrgete uurimine.