Prečo zvuk vypadáva, hoci je využitie CPU nízke? — Pohľad cez buffer a termíny

Počúvate hudbu a zvuk sa z času na čas preruší „lupnutím“. Správca úloh ukazuje využitie CPU okolo 10 %, a predsa je nestabilný len zvuk. Prečo v takej chvíli zvuk vypadáva, hoci má CPU rezervu?

Aj pri nízkom využití CPU môže zvuk vypadnúť, ak doplnenie ďalších zvukových dát nestihne termín. Ďalšie dáta totiž treba odovzdať v čase, keď sa ešte prehráva zvuk, ktorý zostal v bufferi. Doplnenie sa môže oneskoriť napríklad čakaním na dáta alebo zámky či vplyvom DPC/ISR na potrebnom logickom procesore, a to aj vtedy, keď CPU ako celok nie je vyťažené. Exclusive-Mode Streams, CPU Analysis

Samotné počuté „lupnutie“ však ešte nedokazuje underrun. Podobné príznaky môže spôsobiť aj samotná nahrávka, aplikácia, zvukové efekty, výstupné zariadenie a ďalšie prvky. Najprv s tou istou nahrávkou porovnávajte zmenu vždy jednej podmienky a jej vrátenie späť; ak ani tak príčinu nezúžite, zaznamenajte úsek pred výpadkom a po ňom. Fix distorted or crackling audio in Windows

Tento článok sa venuje tejto otázke aj otázkam, ktoré z nej vyplývajú: „Stačí zväčšiť buffer?“ a „Čo porovnať a čo zaznamenať, aby sa príčina zúžila?“ Článok neurčuje príčinu konkrétnej poruchy len na základe využitia CPU alebo počutého zvuku.

Článok sa zameriava predovšetkým na zvukový výstup vo Windows 11. Porovnáva vstavaný, káblový, USB, Bluetooth a ďalšie výstupy a pri softvéri na tvorbu hudby (DAW) sa venuje aj porovnaniu v prípadoch, keď aplikácia alebo ovládač ponúka nastavenie bufferu. Návrh celého nahrávacieho reťazca ani diagnostiku bezdrôtovej komunikácie jednotlivých zariadení komplexne nepokrýva.

Ako základný príklad slúži vo výklade zdieľaný režim. Skutočná cesta, veľkosť bufferu a perióda spracovania sa líšia podľa aplikácie, API, ovládača a zariadenia a neexistuje ani obrazovka nastavenia bufferu spoločná pre všetky aplikácie. Low Latency Audio

Využitie CPU, zostatok 10 ms, časy doplnenia a ďalšie hodnoty uvedené v článku sú predpoklady na vysvetlenie. Nejde o správu o nameranom výskyte problému alebo zlepšení na konkrétnom počítači. Postupy v druhej časti sú kontrolné kroky, ktoré vykonáte vo svojom prostredí.

Princíp si môžete prečítať postupne od nasledujúcej časti „Buffer prehrávania zvuku“. Postupy na vyšetrenie výpadkov zvuku nájdete v častiach „Porovnanie podmienok výskytu“ a „Záznam výpadku zvuku pomocou WPR“.

V diagrame plná čiara označuje vzťah, ktorý platí vždy, a prerušovaná čiara vzťah podmienený (podmienky sú uvedené pri každom vzťahu na stránke s podrobnosťami). Úplný zoznam vzťahov (spolu 5, s dôkazmi a mierou istoty) a definície hlavných pojmov sú zhromaždené na stránke s podrobnosťami znalostnej mapy (v japončine). Údaje: JSON-LD / Turtle

Buffer prehrávania zvuku

Samotným uložením hudobného súboru reproduktor nezaznie. Aplikácia pripraví zvukové dáta a cez Windows a ovládač ich doručí výstupnému zariadeniu. Buffer prehrávania zvuku je oblasť, do ktorej sa dočasne ukladajú dáta, ktoré sa budú prehrávať o chvíľu. Kým zariadenie prehráva aktuálne dáta, dodávajúca strana pripraví ďalšie a doplní ich. Rendering a Stream

flowchart TB
    accTitle: Najprv nahromadiť zvuk o niečo dopredu, potom prehrávať
    accDescr: Postup, pri ktorom sa pripravené zvukové dáta doplnia do bufferu a kým prehrávanie na strane zariadenia pokračuje, pripravia sa ďalšie dáta.
    A["Pripraviť ďalší zvuk"] --> B["Doplniť do bufferu"]
    B --> C["Prehrať nahromadený zvuk"]
    C -.->|"Skôr, než sa minie"| A

Obrázok 1: Aby prehrávanie pokračovalo, doplňovanie musí stíhať strane, ktorá zvuk spotrebúva.

Obrázok 1 je koncepčný diagram, ktorý zobrazuje len vzťah medzi doplňovaním a spotrebou. Nepredstavuje viacero bufferov na skutočnej zvukovej ceste ako jednu fyzickú oblasť. Low Latency Audio

Úlohou bufferu je pohltiť krátke časové rozdiely medzi stranou, ktorá zvuk pripravuje, a stranou, ktorá ho spotrebúva, a zabezpečiť tak plynulé prehrávanie. Kapacita bufferu a množstvo neprehratých dát, ktoré sú v ňom práve teraz, sú však dve rôzne veci. To, že má buffer „kapacitu 10 ms“, neznamená, že v ňom vždy zostáva 10 ms zvuku. Rendering a Stream

Časové obmedzenie, podľa ktorého treba ďalšie potrebné dáta doručiť skôr, než sa minú práve prehrávané dáta, tu nazývame termín doplnenia. Pri spracovaní zvuku je nevyhnutné, aby bolo všetko „pripravené do času, keď má zaznieť“. Nestačí, že „sa to nakoniec vypočítalo“. Stav, keď dodávka nestihne a dáta na prehrávanie sa minú, sa nazýva underrun a vedie k výpadkom zvuku alebo k cvaknutiam. Ani keď dáta dorazia neskôr, výpadok, ktorý už zaznel, sa dodatočne zaplniť nedá. Exclusive-Mode Streams

Cesta zvukových dát

V bežnom zdieľanom režime prevezme dáta pripravené prehrávacou aplikáciou audio engine systému Windows, zmieša viacero zvukov alebo použije efekty a potom ich odovzdá ovládaču a výstupnému zariadeniu. Prehrávacia aplikácia sa podieľa na načítaní nahrávky aj na dodávaní dát do výstupu; ovládač a výstupné zariadenie prenesú dáta na stranu zariadenia a prehrajú ich. Low Latency Audio

flowchart TB
    accTitle: Cesta zvukových dát v zdieľanom režime
    accDescr: Dáta pripravené prehrávacou aplikáciou audio engine zmieša a spracuje efektmi, odovzdá ich ovládaču a výstupné zariadenie ich prehrá.
    A["Prehrávacia aplikácia: príprava dát"] --> E["Audio engine: mixovanie, efekty"]
    E --> D["Ovládač: prenos do zariadenia"]
    D --> O["Výstupné zariadenie: prehrávanie"]

Obrázok 2: Príklad zdieľaného režimu. Spracovanie a buffery na ceste sa líšia podľa API a zariadenia.

Spracovanie a buffery môžu byť aj na strane zariadenia, takže celkové oneskorenie neurčuje len buffer na strane aplikácie. Tento výklad vychádza z cesty v zdieľanom režime a neznamená, že pri všetkých API prechádzajú dáta rovnakým spracovaním. Low Latency Audio

Doplnenie pri zostatku 10 ms

Predpokladajme, že v bufferi teraz zostávajú neprehraté dáta ešte na 10 ms. Ak príde ďalšie doplnenie o 8 ms, nadviaže ešte pred minutím zostatku; ak sa však doplniť nedá skôr ako o 12 ms, v tomto zjednodušenom príklade sa dáta minú v čase 10 ms.

flowchart TB
    accTitle: Pri rovnakom zostatku 10 ms rozhoduje o výsledku čas doplnenia
    accDescr: Na predpokladanom príklade so zostatkom 10 ms dát na prehrávanie ukazuje, že doplnenie o 8 ms to stihne, kým doplnenie o 12 ms príde až po ich minutí.
    A["Zostáva 10 ms"] --> B{"Ďalšie doplnenie"}
    B -->|"O 8 ms"| C["Plynulé pokračovanie"]
    B -->|"O 12 ms"| D["Minie sa po 10 ms"]

Obrázok 3: Príklad so zjednodušeným časovaním. Dôležité nie je len to, či sa doplnenie podarilo, ale aj kedy.

Využitie CPU a oneskorené doplnenie

Využitie CPU ukazuje, aké vyťažené bolo CPU počas určitého časového úseku. To je iná otázka ako to, či sa spracovanie zvuku mohlo vykonať v okamihu, keď to bolo potrebné. Aj keď má CPU väčšinu sekundy rezervu, stačí jediný úsek, v ktorom sa 12 ms nedá doplniť, a toto jediné oneskorenie môže spôsobiť výpadok. Rezerva výpočtového výkonu, ktorá zostane neskôr, už zmeškaný čas prehrávania nevráti. CPU Analysis

flowchart TB
    accTitle: Priemerná rezerva a jediné oneskorené doplnenie
    accDescr: Aj keď má CPU väčšinu sekundy rezervu, jediný úsek, v ktorom sa 12 ms nedá doplniť, môže týmto jediným oneskorením spôsobiť výpadok zvuku.
    A["CPU má väčšinu sekundy rezervu"] --> B["Raz sa 12 ms nedá doplniť"]
    B --> C["Zvuk vypadne práve vtedy"]

Obrázok 4: Ani priemerná rezerva nevráti zmeškaný čas prehrávania.

Čas, ktorý zostáva do termínu, neuberá len samotný výpočet. Patrí sem aj čakanie, kým sa spracovanie začne, a čakanie, kým dorazia potrebné dáta. Preto sa pri vyšetrovaní nepýtame len „Koľko percent malo CPU?“, ale otázku meníme na „Na čo čakal ďalší zvuk v okamihu, keď zvuk vypadol?“

Čakanie na dáta a zámky

Predstavte si, že spracovanie, ktoré pripravuje zvukové dáta, čaká na dokončenie načítania súboru. Rovnako je to, keď čaká na zámok, ktorý drží iné spracovanie v aplikácii. Čakajúce spracovanie samo CPU veľmi nevyužíva, no na strane zariadenia prehrávanie pokračuje a zostávajúceho zvuku ubúda. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Prehrávanie pokračuje aj počas čakania, ktoré nevyužíva CPU
    accDescr: Kým spracovanie zvuku čaká na dáta alebo zámok, CPU nevyužíva, ale prehrávanie pokračuje, zostatok ubúda a pri oneskorenom doplnení sa buffer môže minúť.
    A["Spracovanie zvuku čaká na dáta"] --> B["Toto spracovanie nevyužíva CPU"]
    B --> C["Prehrávanie medzitým pokračuje"]
    C --> D["Pri oneskorení sa zásoba minie"]

Obrázok 5: To, že spracovanie nevyužíva CPU, neznamená, že potrebná práca je hotová.

DPC, ISR a zvukové vlákno

ISR je spracovanie, ktoré obsluhuje prerušenie od zariadenia. DPC je mechanizmus, ktorý zvyšok práce odloží na neskôr, aby obsluha prerušenia zostala krátka. Bežné DPC sa vykonávajú pred bežnými vláknami na tom istom logickom procesore a kým beží bežné DPC alebo ISR, na danom logickom procesore sa bežné vlákna vykonávať nemôžu. Introduction to DPCs, CPU Analysis

Aj keď má CPU ako celok rezervu, dodávka sa môže oneskoriť, ak sa tieto spracovania na procesore potrebnom pre zvuk predlžujú alebo sa často opakujú. Materiál Microsoftu o analýze výkonu pri zvuku a videu uvádza medzi možnými príčinami výpadkov zvuku aj dlhé DPC/ISR ovládačov siete, úložiska, grafiky a ďalších. Nemusí teda stačiť skúmať len zariadenie, ktoré vydáva zvuk. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Keď obsluha zariadenia oneskorí vykonávanie zvuku
    accDescr: Ak sa bežné DPC alebo ISR na procesore potrebnom pre spracovanie zvuku predĺžia, vykonanie vlákna sa oneskorí, čo môže ovplyvniť termín doplnenia.
    A["DPC, ISR na tom istom CPU"] -->|"Ak sa predĺžia"| B["Zvuk musí čakať na vykonanie"]
    B --> C["Doplnenie ďalšieho zvuku mešká"]
    C --> D["Keď sa zostatok minie, výpadok"]

Obrázok 6: Aj spracovanie iných zariadení, než je to, ktoré vydáva zvuk, môže nepriamo ovplyvniť doplňovanie zvuku.

Univerzálnu hranicu typu „ak DPC trvá najviac toľko a toľko mikrosekúnd, zvuk nevypadne na žiadnom počítači“ stanoviť nemožno. Varovné hodnoty v materiáli o hodnotení výkonu platia pre jeho podmienky hodnotenia a nepovažujeme ich za bezpečnostné kritérium oddelene od skutočného termínu doplnenia a rezervy bufferu. Results for the Streaming Media Performance Assessment

Veľkosť bufferu a oneskorenie prehrávania

Ak pri inak rovnakých podmienkach nahromadíte vopred viac zvuku, dočasné oneskorenia doplnenia sa pohltia ľahšie, no novo vytvorený zvuk čaká za zvukom, ktorý sa už nahromadil. Čakanie, ktoré je pri samotnom počúvaní hudby prijateľné, sa pri hre na klávesoch alebo pri odpočúvaní vlastného hlasu upraveného z mikrofónu prejaví ako rušivý rozdiel medzi úkonom a zvukom. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Rezerva bufferu a oneskorená odozva
    accDescr: Viac vopred nahromadeného zvuku ľahšie pohltí dočasné oneskorenia doplnenia, ale zároveň predĺži čakanie, kým sa prehrá nový zvuk.
    A["Nahromadiť vopred viac zvuku"] --> B["Ľahšie pohltí oneskorené doplnenie"]
    B -->|"Za cenu, že"| C["Nový zvuk čaká v rade"]
    C --> D["Zvuk mešká za úkonom"]

Obrázok 7: Zväčšenie bufferu je úprava, ktorá vytvára rezervu za cenu rýchlosti odozvy.

Neplatí „čím menší, tým výkonnejší“ ani „čím väčší, tým správnejší“. Cieľom je zachovať potrebnú rýchlosť odozvy a zároveň získať rezervu, pri ktorej zvuk nevypadáva.

Zväčšenie bufferu vytvára rezervu na dočasné oneskorenia dodávky. Ak samotná priemerná dodávka nestíha spotrebu, zväčšenie konečného bufferu len predĺži čas, kým sa minie, a nevyrieši ani odpojenie zariadenia. Nie je to ani odporúčanie, že výhradný režim všetko vyrieši. Exclusive-Mode Streams

480 rámcov zvuku pri 48 kHz

Rámec PCM je jednotka, ktorá spája vzorky všetkých kanálov prehrávané v tom istom okamihu. Pri sterea sa teda pri výpočte času počet rámcov nezdvojnásobuje. Dĺžku zvuku, ktorú predstavuje počet rámcov, vypočítate ako „počet rámcov ÷ vzorkovacia frekvencia“; 480 rámcov pri 48 kHz je 480 ÷ 48000 sekundy, teda 10 ms. Ak pri 48 kHz zvýšite počet rámcov, predĺži sa aj čas zvuku, ktorý sa dá nahromadiť. Rendering a Stream

Tento čas nie je totožný s celkovým oneskorením od stlačenia klávesu po počutie zvuku. Pribúda totiž aj čas aplikácie, ovládača, zariadenia a ďalších bufferov či spracovania. Aj hodnoty nastavení v DAW čítajte až po overení jednotky a toho, ktorého bufferu sa týkajú. Low Latency Audio

flowchart TB
    accTitle: Čas vypočítaný z počtu rámcov a celkové oneskorenie
    accDescr: 10 ms, ktoré vzniknú vydelením 480 rámcov číslom 48000, je čas, ktorý predstavuje buffer, a celkové oneskorenie od klávesu po zvuk zahŕňa navyše spracovanie v aplikácii, ovládači, zariadení a ďalšie.
    A["480 ÷ 48000"] --> B["10 ms, ktoré predstavuje buffer"]
    B -->|"Pridá sa ďalšie spracovanie"| C["Celkové oneskorenie od klávesu po zvuk"]

Obrázok 8: Čas vypočítaný z počtu rámcov je len časťou celkového oneskorenia.

Porovnanie podmienok výskytu

Najprv zúžte kombináciu, pri ktorej sa problém prejavuje, a k podrobnému záznamu prejdite len v prípade potreby. Nasledujúci postup slúži na overenie príčiny; nie je to zoznam opatrení, pri ktorom by ste všetky zmeny nastavení vykonali naraz.

Uložte si prácu a skúšajte až po skončení skutočných porád alebo nahrávania, pri hlasitosti, ktorá nezaťažuje sluch. Poznačte si pôvodný výstup, vylepšenia zvuku, hodnotu bufferu a podobne, aby ste ich mohli vrátiť. Položky, ktorých nastavenie nie je k dispozícii, preskočte a kvôli zobrazeniu nastavenia nemeňte register ani nič podobné.

1. Zvoľte si jednu krátku nahrávku a dĺžku pozorovania a overte, či sa problém prejaví za pôvodných podmienok.

   Zaznamenajte verziu Windows, názov a verziu aplikácie, výstupné zariadenie, spôsob pripojenia a verziu ovládača. Poznačte si aj čas, úkon a počet výpadkov zvuku. Ak sa problém za pôvodných podmienok neprejaví, nepovažujte to za zlepšenie a vráťte sa k zisťovaniu podmienok, za ktorých sa prejavuje.

2. Z nasledujúcej tabuľky vyberte jedno porovnanie a prehrávajte so zmenou len tejto podmienky.

   Porovnávaná podmienka	Čo zisťujete
   Lokálne uložená nahrávka a prehrávanie cez internet	Či sa problém prejavuje len pri prehrávaní cez internet. Ak sa pri rovnakom obsahu líši formát alebo cesta spracovania, zaznamenajte aj to.
   Tá istá nahrávka v inej aplikácii	Či sa problém sústreďuje na konkrétnu aplikáciu.
   Bluetooth alebo iný výstup oproti vstavanému či káblovému výstupu	Či sa problém sústreďuje na konkrétnu výstupnú cestu.
   Vylepšenia zvuku zapnuté a vypnuté	Či sa správanie mení v kombinácii so spracovaním efektov.
   Aktuálny buffer v DAW a podobných aplikáciách a o stupeň väčšia hodnota	Či sa správanie zmení, keď zväčšíte rezervu vopred nahromadeného zvuku. Či je prijateľné aj oneskorenie od úkonu po zvuk.

3. Ak porovnávate vylepšenia zvuku, na príslušnom výstupe ich dočasne vypnite.

   V systéme Windows otvorte „Nastavenia“ → „Systém“ → „Zvuk“, vyberte príslušný výstup a v prostrediach, kde je to dostupné, vypnite „Vylepšenia zvuku“. Ak sa zobrazenie alebo dostupnosť položiek líši, pozrite si pokyny pre danú verziu a zariadenie. Fix distorted or crackling audio in Windows

4. Zmenené nastavenie vráťte späť a skúste to znova s tou istou nahrávkou a dĺžkou pozorovania.

   Porovnajte vedľa seba výsledky pre „pôvodné podmienky“, „podmienky s jednou zmenou“ a „podmienky po vrátení späť“. Zmenu bez účinku vráťte do pôvodného stavu a až potom prejdite na ďalšie porovnanie. Ak budete kombinácie nastavení neustále meniť, nebudete vedieť, čo zabralo.

5. Ak chcete vyskúšať zmenu ovládača, urobte to až po overení oficiálneho zdroja a spôsobu obnovy.

   Použite Windows Update alebo oficiálnu distribúciu výrobcu zariadenia a zaznamenajte verziu a nastavenia pred zmenou a po nej. Vopred si overte, či sa dá zmena vrátiť, a na spravovaných počítačoch sa poraďte so správcom. To, že sa zvuk hneď po aktualizácii raz prehral bez problémov, ešte neznamená vyriešenie; overte to za rovnakých podmienok výskytu. Fix distorted or crackling audio in Windows

Cieľom je záznam, ktorý priraďuje príznak k podmienkam, napríklad „prejaví sa v tejto aplikácii pri použití tohto výstupu“. Aj keď nájdete nastavenie, ktoré pomohlo, oddeľte to od potvrdenia príčiny.

flowchart TB
    accTitle: Porovnanie so zmenou jednej podmienky a jej vrátením
    accDescr: S tou istou nahrávkou sa overí, či sa problém prejaví, zmení sa jedna podmienka, napríklad aplikácia alebo výstup, a zaznamená sa aj výsledok po vrátení späť.
    A["Prehrať v pôvodnej kombinácii"] --> B["Prehrať so zmenou jednej podmienky"]
    B --> C["Vrátiť späť a prehrať"]
    C --> D["Zaznamenať podmienky a čas výpadku"]

Obrázok 9: Dôležitejšie než jednorazové zlepšenie je overiť, že podmienky a príznaky si opakovane zodpovedajú.

Opakovateľnosť pred zmenou podmienok a po nej

„Príznaky sa podarilo potlačiť“, „podmienky sa podarilo zúžiť“ a „podarilo sa určiť základnú príčinu“ sú rôzne dosiahnuté stupne. Záver zaznamenajte v rozsahu, ktorý ste skutočne pozorovali.

flowchart TB
    accTitle: Tri výsledky, ktoré naznačujú súvislosť s podmienkou
    accDescr: Ak sa problém za pôvodných podmienok prejaví, po zmene jednej podmienky sa zlepší a po vrátení späť sa znova prejaví, je to indícia súvislosti s touto podmienkou, ktorú však treba oddeliť od potvrdenia príčiny.
    A["Prejaví sa za pôvodných podmienok"] --> B["Po jednej zmene sa zlepší"]
    B --> C["Po vrátení sa znova prejaví"]
    C --> D["Indícia súvislosti s podmienkou"]

Obrázok 10: Ani keď sú splnené všetky tri, máte len indíciu súvislosti.

Nízke využitie CPU nie je dôkazom, že zvuk dodržal svoj termín. Zároveň sa len z toho, že zvuk vypadol, nedá tvrdiť, že základnou príčinou bolo oneskorené doplnenie. Porovnajte nahrávku, spracovanie v aplikácii, efekty, výstupnú cestu a ďalšie faktory a posudzujte v rozsahu, ktorý ste pozorovali. Fix distorted or crackling audio in Windows

Ak zavediete dočasné obchádzkové riešenie, zaznamenajte pôvodné nastavenie, obsah zmeny, dĺžku pozorovania, či sa problém zopakoval, a prijateľné oneskorenie. Ak základná príčina nie je potvrdená, zaznamenajte aj to.

Záznam výpadku zvuku pomocou WPR

Tento krok vykonajte, ak príčinu nezúžite samotným porovnávaním podmienok alebo ak skúmate spracovanie na strane ovládača. WPR je nástroj na záznam a WPA nástroj na analýzu uloženej časovej osi. Pripravte si Windows Performance Toolkit, oprávnenia potrebné na záznam a miesto na uloženie ETL. Ak chcete nástroj nainštalovať a zaznamenávať na spravovanom počítači, požiadajte o to správcu. Zobrazované názvy a dostupné profily overte v nainštalovanej verzii. Windows Performance Recorder

ETL môže obsahovať názvy procesov, cesty k súborom a podobné údaje. Pred záznamom si overte interné pravidlá a to, s kým budete záznam zdieľať, a neprikladajte ho len tak na verejné miesta. Ak beží iná relácia záznamu, nezastavujte ju svojvoľne a poraďte sa so zodpovednou osobou. WPR How-to Topics

1. Vo WPR otvorte „More Options“ a vyberte profil záznamu, ktorý zodpovedá vášmu cieľu.

   Medzi štandardnými profilmi sú „Audio glitches“ a „CPU usage“. Zvoľte nastavenie, s ktorým môžete skúmať nespojitosti zvuku a činnosť CPU. Dostupné profily, zobrazované názvy a zbierané údaje overte v nainštalovanej verzii a nenastavujte dlhý záznam všetkých typov. Built-in Recording Profiles

2. Záznam spustite ešte predtým, ako vyvoláte výpadok zvuku.

   Ak sa zobrazí výzva na zastavenie existujúceho záznamu, nepokračujte, zrušte spustenie a poraďte sa so zodpovednou osobou. Podmienky zosúlaďte s prípadom bez záznamu a nevylučujte ani možnosť, že samotná záťaž záznamu príznaky zmení. WPR How-to Topics

3. Prehrávajte za podmienok, ktoré ste našli porovnávaním, a poznačte si čas výpadku a vykonaný úkon.

   Pred príznakom a po ňom zachyťte aj kúsok úseku bez problémov. Pri zázname, v ktorom sa problém neprejavil, túto skutočnosť jasne uveďte a nepovažujte ho za záznam, ktorý zachytil príčinu.

4. Po vyvolaní problému ukončite záznam tlačidlom „Save“ a uložte súbor ETL.

   Tlačidlo „Cancel“ záznam neuloží. Poznačte si miesto uloženia, podmienky výskytu, či záznam vznikol a či sa zobrazilo varovanie o strate udalostí. Pri zázname so stratou udalostí nepovažujte nezachytené úseky za bezproblémové. WPR How-to Topics

Keď máte súbor ETL a poznámky o čase, úkone a podmienkach výpadku zvuku, ste pripravení na porovnanie vo WPA. Samotné uloženie záznamu ešte nezaručuje, že sa podarilo zachytiť potrebné udalosti. Obsah skontrolujete v nasledujúcej časti „Vykonávanie a čakanie okolo výpadku“.

flowchart TB
    accTitle: Krátky záznam, ktorý zachytí výpadok zvuku
    accDescr: Záznam sa spustí vo WPR, príznak sa vyvolá a poznačí sa čas, záznam sa zastaví a uloží a potom sa skúma vo WPA.
    A["Spustiť záznam vo WPR"] --> B["Vyvolať výpadok za rovnakých podmienok"]
    B --> C["Poznačiť čas a úkon, uložiť"]
    C --> D["Priblížiť okolité úseky vo WPA"]

Obrázok 11: Nestačí pozrieť sa na využitie CPU po skončení príznaku; potrebujete záznam úseku, v ktorom príznak nastal.

Vykonávanie a čakanie okolo výpadku

Pripravte si uložený súbor ETL a poznámku s časom výskytu. Nasledujúce kroky sú východiskom vyšetrovania vo WPA. Ak bude potrebná podrobná analýza vrátane zásobníkov a symbolov, dbajte na zaobchádzanie so záznamom a požiadajte o ňu správcu alebo vývojárov.

1. Otvorte ETL vo WPA a na základe zachytených zvukových udalostí a času výskytu priblížte úsek pred výpadkom a po ňom.

   Na porovnanie si ponechajte aj úsek bez príznakov. Nepozerajte len na rebríček maximálnych hodnôt; porovnávajte pri zosúladenom časovom rozsahu.

2. V tom istom rozsahu skontrolujte „DPC/ISR“ a „CPU Usage (Precise)“.

   Ak potrebné údaje chýbajú, overte, či ich profil dokáže zachytiť, a vráťte sa k záznamu vo WPR. To, že niečo nie je zaznamenané, neznamená, že problém nenastal. CPU Analysis, Built-in Recording Profiles

3. Rozlíšte, či vlákno súvisiace so zvukom bolo pripravené na vykonanie, ale čakalo v poradí, alebo čakalo na dáta či niečo iné.

   V prvom prípade porovnajte, či na príslušnom logickom procesore dlho nebežali DPC/ISR alebo iné spracovanie. V druhom prípade pomocou zachytených udalostí a zásobníkov sledujte, čo čakanie ukončilo. Aj bežiace vlákno môže byť zastavené prerušením, preto sa neobmedzujte len na čas v stave Ready a prekryte aj úseky DPC/ISR. CPU Analysis

4. Zaznamenajte spolu časovú zhodu s výpadkom zvuku, príslušný procesor a výsledky po zmene podmienok.

   Len podľa názvu modulu s dlhými DPC/ISR neurčujte za príčinu konkrétne zariadenie alebo ovládač. Môžete sa pozerať na vysokú hodnotu z iného času alebo na spoločnú časť, cez ktorú prechádza viacero zariadení.

flowchart TB
    accTitle: Skúmanie spôsobu čakania v úseku výpadku
    accDescr: Úsek pred výpadkom a po ňom sa priblíži a skúma sa stav zvukového vlákna. Ak bolo pripravené a čakalo v poradí, porovná sa s DPC alebo ISR na tom istom procesore, a ak čakalo na dáta a podobne, sleduje sa spracovanie, ktoré čakanie ukončilo.
    A["Priblížiť úsek okolo výpadku"] --> B{"Stav vlákna"}
    B -->|"Čaká v poradí"| C["DPC, ISR"]
    B -->|"Čaká na dáta"| D["Čo ukončilo čakanie"]

Obrázok 12: Nevyberajte len maximálne hodnoty; čítajte ich prekryté s úsekom, v ktorom bolo spracovanie zvuku potrebné.

Ak príčinu neurčíte, odovzdajte vyšetrovanie ďalej ako nepotvrdené. Priložte verzie OS, aplikácie, zariadenia a ovládača, postup na vyvolanie problému, výsledky pred zmenou a po nej, čas výskytu, použitý profil zberu a informáciu, či sa zobrazilo varovanie o strate udalostí. ETL zdieľajte podľa interných pravidiel len s tými, ktorí majú vyšetrovanie na starosti.

Načítanie vopred v zvukových aplikáciách

Ak vyvíjate vlastnú zvukovú aplikáciu, navrhnite ju tak, aby spracovanie, ktoré plní ďalší buffer, zakaždým stihlo termín. WASAPI ponúka spôsob, ako dostávať udalosť v okamihu, keď je možné buffer spracovať. Exclusive-Mode Streams

MMCSS je mechanizmus, ktorý prideľuje prostriedky CPU vláknam multimediálneho spracovania s časovými obmedzeniami. Nemá funkcie, ktoré by vopred pripravili dáta z disku alebo odstránili čakanie na zámky. Aj keď prideľovanie cez MMCSS využijete, návrh, ktorý pripraví dáta a obmedzí čakanie, je potrebný zvlášť. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Za čo zodpovedá MMCSS
    accDescr: MMCSS prideľuje prostriedky CPU vláknam spracovania s časovými obmedzeniami, no prípravu dát a obmedzenie čakania na zámky rieši samostatný návrh.
    M["MMCSS: prideľuje prostriedky CPU"] -.->|"Potrebné zvlášť"| D["Príprava dát a menej čakania"]

Obrázok 13: Prideľovanie prostriedkov CPU a návrh, vďaka ktorému dáta prídu včas, sú dve rôzne úlohy.

Zásadou návrhu je oddeliť spracovanie, ktoré číta zo súborov alebo zo siete, od spracovania, ktoré odovzdáva zvuk. Prípravu s ťažko predvídateľným trvaním vykonajte vopred a na odovzdávanie použite vopred alokovaný buffer. Na strane zvuku zabezpečte, aby nebolo potrebné čakať na odpoveď používateľského rozhrania, dlhé zámky ani synchrónny zápis do logu.

flowchart TB
    accTitle: Oddelenie ťažko predvídateľnej prípravy od dodávky zvuku
    accDescr: Návrh, pri ktorom sa načítanie a podobné kroky vykonajú vopred, pripravené dáta sa cez buffer odovzdajú spracovaniu zvuku a dlhé čakanie tesne pred termínom sa obmedzí.
    A["Pripraviť dáta vopred"] --> B["Vopred alokovaná odovzdávacia oblasť"]
    B --> C["Spracovanie zvuku odovzdá potrebnú časť"]
    C --> D["Dodávka do zvukového výstupu"]

Obrázok 14: Časovo náročnú prácu presuňte mimo okamih tesne pred odovzdaním zvuku.

Ak sa pripravujúca strana na dlhšie zastaví, zásoba sa minie aj pri tomto oddelení. Zaznamenávajte nielen priemerný čas spracovania, ale aj prípady, keď sa vyskytlo dlhé spracovanie alebo čakanie, a počet prípadov, keď sa dodávka nestihla, a to spôsobom, ktorý spracovanie zvuku neruší. Skutočne zvolenú veľkosť bufferu a periódu overte cez API alebo ovládač a nepredpokladajte, že sa zadaná hodnota prevzala bez zmeny. Rendering a Stream, Low Latency Audio

Číselné príklady aj príklady návrhu slúžia na vysvetlenie; nie sú to odporúčané hodnoty nastavení pre konkrétne zariadenia ani záruka, že zvuk nebude vypadávať v ľubovoľnom prostredí.

Vplyv priority v reálnom čase

Plošne neodporúčame, aby používateľ prepol celý prehrávač na prioritu „V reálnom čase“. Hrozí, že to bude brániť iným dôležitým spracovaniam, a ani zvýšenie priority bežného vlákna neodstráni čakanie spôsobené DPC/ISR ani čakanie na dáta a zámky. Pri vývoji sa používajú mechanizmy ako MMCSS a návrh, ktorý dlhé čakanie do dodávky zvuku nevnáša. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Čakanie, ktoré zostane aj pri priorite v reálnom čase
    accDescr: Ani pri priorite prehrávača V reálnom čase bežné vlákno nepredbehne DPC ani ISR na tom istom procesore, čakanie na dáta a zámky zostáva a hrozí aj brzdenie iných dôležitých spracovaní.
    A["Prehrávač s prioritou v reálnom čase"] --> B["DPC, ISR nepredbehne"]
    B --> C["Čakanie na dáta a zámky zostáva"]
    C --> D["Riziko brzdenia iných procesov"]

Obrázok 15: Ani vyššia priorita neodstráni čakanie, ktoré oneskoruje doplňovanie zvuku.

Súvisiace články

• „Plánovanie procesora“ vo Windows a nastavenie služieb na pozadí
• Ako bezpečne zistiť príčinu 100 % využitia disku vo Windows
• Prečo je RDP pomalé, hoci je pripojenie rýchle?

Zdroje

• Microsoft Learn, Rendering a Stream. Dodávanie dát do bufferu prehrávania, zostatok, skutočná veľkosť bufferu a definícia rámca PCM.
• Microsoft Learn, Exclusive-Mode Streams. Načasovanie dodania bufferu a chyby zvuku, vyváženie s oneskorením, dodávanie riadené udalosťami. Nejde o plošné odporúčanie samotného výhradného režimu.
• Microsoft Learn, Low Latency Audio. Zvuková cesta vo Windows, buffery, zariadenia, spracovanie efektov a oneskorenie, kompromisy pri nízkej latencii.
• Microsoft Learn, CPU Analysis. Logické procesory, stavy vlákien Ready/Waiting, vzťah medzi DPC/ISR a vykonávaním vlákien, analýza CPU vo WPA.
• Microsoft Learn, Introduction to DPCs. Mechanizmus, ktorý skracuje obsluhu prerušenia a zvyšok práce presúva do DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Dlhé a časté DPC/ISR, nedostatočná dodávka dát a chyby zvuku. Varovné hodnoty hodnotenia nezovšeobecňujeme na bezpečnostné kritérium pre všetky zariadenia.
• Microsoft Support, Fix distorted or crackling audio in Windows. Kontrola vylepšení zvuku, formátu, ovládača a ďalších položiek.
• Microsoft Learn, Windows Performance Recorder. Záznam ETW a analýza vo WPA, používanie Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options vo WPR a štandardné profily ako Audio glitches a CPU usage.
• Microsoft Learn, WPR How-to Topics. Spustenie záznamu a uloženie cez Save, konflikt s existujúcimi reláciami, upozornenia na osobné údaje a stratu udalostí.
• Microsoft Learn, Multimedia Class Scheduler Service. Prideľovanie prostriedkov CPU multimediálnemu spracovaniu s časovými obmedzeniami.
• Microsoft Learn, Scheduling Priorities. Priority procesov a vlákien a upozornenia týkajúce sa priority v reálnom čase.

Súvisiace články

Nedávne články s rovnakými štítkami. Prehĺbte si tému pomocou úzko súvisiacich textov.

Súvisiace témy

Toto sú stránky tém blízke téme tohto článku. Od článku môžete pokračovať k súvisiacim službám a ďalším článkom.

Služby, s ktorými táto téma súvisí

Tento článok nadväzuje na nasledujúce stránky služieb. Začnite tou, ktorá je vám najbližšia.

Často kladené otázky

Zhrnuli sme otázky k téme tohto článku, ktoré sa pri konzultáciách objavujú najčastejšie.

Prečo zvuk vypadáva, hoci je využitie CPU len okolo 10 %?

Zvuk má termín: ďalšie dáta treba doplniť skôr, než sa minú tie, ktoré sa práve prehrávajú. Aj keď je celkové využitie CPU nízke, doplnenie to nemusí stihnúť, ak sa spracovanie zvuku v danom okamihu nemôže vykonať alebo čaká na potrebné dáta. Nie každý výpadok zvuku má túto príčinu a potrebné je aj porovnanie so zmeneným výstupným zariadením alebo aplikáciou.

Odstráni väčší zvukový buffer výpadky zvuku?

Ak sa doplnenie oneskorí len dočasne, väčší buffer to niekedy dokáže pohltiť. Zároveň sa však predĺži čakanie, kým sa nahromadený zvuk prehrá. Nie je to nastavenie, ktoré by odstránilo trvalý nedostatok výpočtového výkonu alebo odpojenie zariadenia. Pri aplikáciách a ovládačoch, ktoré zmenu umožňujú, si poznačte pôvodnú hodnotu a porovnávajte po jednom stupni.

Koľko milisekúnd zvuku predstavuje 480 rámcov pri 48 kHz?

480 ÷ 48000 sekundy, teda 10 milisekúnd. Jeden rámec PCM je jednotka, ktorá spája vzorky všetkých kanálov v tom istom okamihu. Táto hodnota je dĺžka zvuku, ktorú daný počet rámcov predstavuje, nie celkové oneskorenie vrátane zariadenia a aplikácie.

Je ovládač s dlhým časom vykonávania DPC alebo ISR vinníkom výpadkov zvuku?

Môže byť kandidátom, ale len z poradia časov vykonávania to nepotvrdíte. Porovnajte úsek, v ktorom zvuk vypadol, s čakaním zvukového vlákna a s vykonávaním DPC/ISR na tom istom procesore. Len podľa názvu modulu neusudzujte, že ide o chybu konkrétneho zariadenia alebo ovládača, a skontrolujte aj výsledky so zmenenými podmienkami výskytu.

Pomôže, ak prehrávaču nastavím prioritu v reálnom čase?

Plošne to neodporúčame. Ani vyššia priorita bežného vlákna nepredbehne bežné DPC ani ISR na tom istom procesore a nezmizne ani čakanie na dáta či zámky. Vývojári používajú mechanizmy ako MMCSS a návrh, ktorý nevnáša čakanie; používatelia najprv porovnajú podmienky výskytu a výstupnú cestu.

Profil autora

Profilová stránka autora článku.

Go Komura

Zástupca spoločnosti KomuraSoft LLC

Zameriava sa najmä na vývoj softvéru pre Windows, technické konzultácie a vyšetrovanie chýb; má silné stránky v zákazkách, kde zostávajú existujúce aktíva, a pri vyšetrovaní porúch, ktorých príčina nie je dobre viditeľná.