Proč se zvuk přerušuje, i když je využití CPU nízké? – buffer a termíny doplňování

Při poslechu hudby zvuk občas krátce „lupne“ a vypadne. Správce úloh ukazuje využití CPU kolem 10 %, a přesto je nestabilní jen zvuk. Proč se v takové situaci zvuk přerušuje, když má CPU volnou kapacitu?

I při nízkém využití CPU se zvuk může přerušit, pokud se další zvuková data nestihnou doplnit do termínu. Další data je totiž nutné předat v době, kdy se přehrává zvuk, který zůstal v bufferu. Ke zpoždění doplnění kvůli čekání na data nebo zámky či kvůli DPC/ISR na potřebném logickém procesoru dochází i tehdy, když celé CPU není plně vytížené. Exclusive-Mode Streams, CPU Analysis

Samotné slyšitelné „lupnutí“ však nestačí k závěru, že jde o podtečení bufferu. Podobné příznaky vznikají i kvůli nahrávce, aplikaci, zvukovým efektům, výstupnímu zařízení a dalším faktorům. Nejprve se stejnou nahrávkou měňte podmínky po jedné, vracejte je zpět a porovnávejte výsledky; pokud ani tak příčinu nezúžíte, zaznamenejte průběh před výpadkem a po něm. Fix distorted or crackling audio in Windows

Tento článek se zabývá touto otázkou i navazujícími otázkami „stačí zvětšit buffer?“ a „co porovnat a co zaznamenat, aby se příčina zúžila?“. Neslouží k tomu, aby na základě samotného využití CPU nebo slyšeného zvuku určil příčinu konkrétní poruchy.

Článek se týká hlavně zvukového výstupu ve Windows 11. Porovnáváme vestavěné, kabelové, USB, Bluetooth a další výstupy a u softwaru pro tvorbu hudby (DAW) se věnujeme i porovnání v případech, kdy aplikace nebo ovladač nabízí nastavení bufferu. Návrh celého nahrávacího řetězce ani diagnostiku bezdrátové komunikace jednotlivých zařízení článek nepokrývá v úplnosti.

Jako základní příklad ve výkladu slouží sdílený režim. Skutečná cesta, velikost bufferu a perioda zpracování se liší podle aplikace, API, ovladače a zařízení a neexistuje ani obrazovka nastavení bufferu společná všem aplikacím. Low Latency Audio

Využití CPU, zbývajících 10 ms, okamžiky doplnění a další údaje uvedené zde jsou předpoklady zvolené pro účely výkladu. Nejde o zprávu o naměřené reprodukci problému ani o naměřeném zlepšení na konkrétním počítači. Postupy v druhé části článku jsou kontrolní kroky, které provádíte ve svém vlastním prostředí.

Princip si můžete projít postupně, počínaje následující částí „Buffer pro přehrávání zvuku“. Postupy pro zkoumání výpadků zvuku najdete v částech „Porovnání podmínek reprodukce“ a „Záznam výpadků zvuku pomocí WPR“.

Na diagramu plná čára označuje vztah, který platí vždy, a přerušovaná čára vztah podmíněný (podmínky jsou uvedeny u jednotlivých vztahů na podrobné stránce). Úplný seznam vztahů (celkem 5, s doklady a mírou jistoty) a definice hlavních pojmů najdete na podrobné stránce znalostní mapy (v japonštině). Data: JSON-LD / Turtle

Buffer pro přehrávání zvuku

Pouhé uložení hudebního souboru reproduktor nerozezní. Aplikace připraví zvuková data a přes Windows a ovladač je doručí výstupnímu zařízení. Buffer pro přehrávání zvuku je oblast, do které se dočasně ukládají data určená k přehrání v nejbližší chvíli. Zatímco zařízení přehrává aktuální data, dodávající strana připraví další data a buffer jimi doplní. Rendering a Stream

flowchart TB
    accTitle: Zvuk se nejprve nashromáždí s předstihem a pak přehraje
    accDescr: Připravená zvuková data se doplňují do bufferu a během přehrávání na straně zařízení se připravují další data.
    A["Připravit další zvuk"] --> B["Doplnit buffer"]
    B --> C["Přehrát nashromážděný zvuk"]
    C -.->|"před vyčerpáním"| A

Obrázek 1: Aby přehrávání pokračovalo, musí doplňování stíhat stranu, která zvuk spotřebovává.

Obrázek 1 je koncepční schéma, které ukazuje pouze vztah mezi doplňováním a spotřebou. Nepředstavuje více bufferů na skutečné zvukové cestě jako jednu fyzickou oblast. Low Latency Audio

Úkolem bufferu je vyrovnat krátké časové rozdíly mezi stranou, která zvuk připravuje, a stranou, která ho spotřebovává, a zajistit tak plynulé přehrávání. Kapacita bufferu je ale něco jiného než množství nepřehraných dat, která v něm právě jsou. To, že má buffer „kapacitu 10 ms“, neznamená, že v něm vždy zbývá 10 ms zvuku. Rendering a Stream

Časové omezení, podle kterého je nutné potřebná další data doručit dříve, než se přehrávaná data spotřebují, zde nazýváme termínem doplnění. Zpracování zvuku vyžaduje, aby data „byla připravena do okamžiku přehrání“. Samotné „nakonec se to spočítat podařilo“ nestačí. Stav, kdy dodávka nestihne a data k přehrání dojdou, se nazývá podtečení (underrun) a vede k výpadkům zvuku a cvakání. I když data dorazí se zpožděním, výpadek, který už zazněl, nelze dodatečně zaplnit. Exclusive-Mode Streams

Cesta zvukových dat

V běžném sdíleném režimu přijímá data připravená přehrávací aplikací audio engine systému Windows, který smíchá více zvuků a aplikuje efekty, a pak je předá ovladači a výstupnímu zařízení. Přehrávací aplikace se podílí jak na načítání nahrávky, tak na dodávání dat do cíle, a ovladač a výstupní zařízení přenášejí data na stranu zařízení a přehrávají je. Low Latency Audio

flowchart TB
    accTitle: Cesta zvukových dat ve sdíleném režimu
    accDescr: Audio engine smíchá data připravená přehrávací aplikací, aplikuje efekty a předá je ovladači, a výstupní zařízení je přehraje.
    A["Aplikace: příprava dat"] --> E["Audio engine: mix a efekty"]
    E --> D["Ovladač: přenos do zařízení"]
    D --> O["Výstupní zařízení: přehrání"]

Obrázek 2: Příklad sdíleného režimu. Zpracování a buffery po cestě se liší podle API a zařízení.

Zpracování a buffery mohou být i na straně zařízení, takže celkové zpoždění neurčuje jen buffer na straně aplikace. Tento popis vychází z cesty ve sdíleném režimu a neznamená, že data procházejí stejným zpracováním ve všech API. Low Latency Audio

Doplnění při zbývajících 10 ms

Předpokládejme, že v bufferu zbývá ještě 10 ms nepřehraných dat. Pokud další doplnění přijde za 8 ms, zvuk naváže, dokud data ještě zbývají; pokud se však buffer nepodaří doplnit dříve než za 12 ms, v tomto zjednodušeném příkladu data dojdou v čase 10 ms.

flowchart TB
    accTitle: I při stejných zbývajících 10 ms rozhoduje čas doplnění
    accDescr: Za předpokladu zvoleného pro výklad, že zbývá 10 ms dat k přehrání, doplnění za 8 ms stihne termín, kdežto doplnění za 12 ms přijde až po jejich vyčerpání.
    A["Zbývá 10 ms"] --> B{"Další doplnění"}
    B -->|"za 8 ms"| C["Zvuk naváže"]
    B -->|"za 12 ms"| D["Data dojdou v 10 ms"]

Obrázek 3: Příklad se zjednodušeným časem. Důležité není jen to, zda se buffer doplnil, ale i kdy.

Využití CPU a zpožděné doplňování

Využití CPU ukazuje, jak byl procesor vytížen během určitého časového úseku. To je jiná věc než to, zda se zpracování zvuku mohlo spustit v okamžiku, kdy bylo potřeba. I když má CPU po většinu sekundy volnou kapacitu, stačí jediný úsek 12 ms, kdy doplnění není možné, a toto jediné zpoždění může zvuk přerušit. Volná výpočetní kapacita, která zbyde později, už zmeškaný okamžik přehrání nevrátí. CPU Analysis

flowchart TB
    accTitle: Průměrná rezerva a jediné zpožděné doplnění
    accDescr: I když má CPU po většinu sekundy volnou kapacitu, jediný úsek 12 ms bez doplnění může zvuk přerušit.
    A["CPU má většinu sekundy rezervu"] --> B["Jednou 12 ms bez doplnění"]
    B --> C["Tento jediný případ přeruší zvuk"]

Obrázek 4: Ani průměrná rezerva nevrátí zmeškaný okamžik přehrání.

Rezervu do termínu neubírá jen doba výpočtu. Patří sem i čekání na zahájení zpracování a čekání na doručení potřebných dat. Proto se mění i otázka při zkoumání: místo pouhého „kolik procent bylo využití CPU?“ se ptáme „na co čekal další zvuk v okamžiku, kdy zvuk vypadl?“.

Čekání na data a zámky

Předpokládejme, že kód, který připravuje zvuková data, čeká na dokončení čtení souboru. Totéž platí, když čeká na zámek, který drží jiná část aplikace. Samotný čekající kód CPU téměř nevyužívá, na straně zařízení však přehrávání pokračuje a zbývajícího zvuku ubývá. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Přehrávání pokračuje i během čekání, které nevyužívá CPU
    accDescr: Zatímco zpracování zvuku čeká na data nebo zámek, nevyužívá CPU, přehrávání ale pokračuje, zásoba se zmenšuje a při zpožděném doplnění může buffer dojít.
    A["Zpracování zvuku čeká na data"] --> B["Tento kód nevyužívá CPU"]
    B --> C["Přehrávání mezitím pokračuje"]
    C --> D["Zpožděné doplnění: zásoba dojde"]

Obrázek 5: To, že CPU není využité, a to, že je potřebná práce hotová, jsou dvě různé věci.

DPC, ISR a zvukové vlákno

ISR je rutina, která obsluhuje přerušení od zařízení. DPC je mechanismus, který odkládá zbývající práci na později, aby obsluha přerušení byla krátká. Běžné DPC se spouštějí před běžnými vlákny na stejném logickém procesoru, a dokud běží běžné DPC nebo ISR, nemůže tento logický procesor běžná vlákna vykonávat. Introduction to DPCs, CPU Analysis

I když má celé CPU volnou kapacitu, dodávka dat se může zpozdit, pokud se tyto rutiny na procesoru, který zpracování zvuku potřebuje, protahují nebo se často opakují. Materiály Microsoftu k analýze výkonu zvuku a videa uvádějí mezi možnými příčinami výpadků zvuku i dlouhé DPC/ISR ovladačů sítě, úložiště, grafiky a dalších. Nemusí stačit zkoumat jen zařízení, které vydává zvuk. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Když obsluha zařízení zdrží běh zvuku
    accDescr: Pokud se na procesoru potřebném pro zpracování zvuku protahují běžné DPC nebo ISR, běh vlákna se zpozdí, což může ovlivnit termín doplnění.
    A["DPC a ISR na stejném CPU"] -->|"když se protahují"| B["Běh zvuku musí čekat"]
    B --> C["Doplnění se zpozdí"]
    C --> D["Zásoba dojde: výpadek"]

Obrázek 6: Zpracování nesouvisející se zařízením, které vydává zvuk, může nepřímo ovlivnit i doplňování zvukových dat.

Společnou hranici typu „pokud DPC trvá nejvýše tolik a tolik mikrosekund, nebude zvuk vypadávat na žádném PC“ stanovit nelze. Varovné hodnoty v materiálech k hodnocení výkonu platí pro podmínky daného hodnocení a nelze je brát jako bezpečnostní kritérium bez ohledu na skutečný termín doplnění a rezervu v bufferu. Results for the Streaming Media Performance Assessment

Velikost bufferu a zpoždění přehrávání

Když za stejných podmínek nashromáždíte s předstihem víc zvuku, snáze se vyrovnají dočasná zpoždění doplnění, nově vytvořený zvuk však čeká za zvukem, který už je nashromážděný. Čekání, které je při pouhém poslechu hudby přijatelné, začne vadit jako nesoulad mezi akcí a zvukem, když hrajete na klávesy nebo upravujete hlas z mikrofonu a sami si ho posloucháte. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Rezerva v bufferu a zpoždění reakce
    accDescr: Větší množství zvuku nashromážděného s předstihem usnadňuje vyrovnání dočasných zpoždění doplnění, ale prodlužuje i čekání, než se přehraje nový zvuk.
    A["Víc zvuku s předstihem"] --> B["Snáze vyrovná zpoždění"]
    B -->|"za cenu"| C["Nový zvuk čeká vzadu"]
    C --> D["Zvuk zaostává za akcí"]

Obrázek 7: Zvětšení bufferu je úprava, která vytváří rezervu za cenu rychlosti reakce.

Neplatí „čím menší, tím výkonnější“ ani „čím větší, tím správnější“. Je třeba zachovat potřebnou rychlost reakce a zároveň zajistit rezervu, při které zvuk nevypadává.

Zvětšení bufferu vytváří rezervu pro dočasná zpoždění dodávky. Pokud průměrná dodávka sama nestačí na spotřebu, zvětšení konečného bufferu jen prodlouží dobu, než dojde, a neodstraní ani odpojování zařízení. Není to ani doporučení, že exkluzivní režim všechno vyřeší. Exclusive-Mode Streams

Zvuk 48 kHz, 480 rámců

Rámec PCM je jednotka, která sdružuje vzorky všech kanálů přehrávané ve stejném okamžiku. To, že jde o stereo, neznamená, že se při výpočtu času počet rámců zdvojnásobuje. Délku zvuku, kterou představuje počet rámců, vypočítáte jako „počet rámců ÷ vzorkovací frekvence“; 480 rámců při 48 kHz odpovídá 480 ÷ 48000 s, tedy 10 ms. Když při 48 kHz zvýšíte počet rámců, prodlouží se i doba zvuku, kterou lze nashromáždit. Rendering a Stream

Tento čas není totéž co celkové zpoždění od stisknutí klávesy po zaznění zvuku. Přidává se totiž i čas aplikace, ovladače, zařízení a dalších bufferů a zpracování. Hodnoty nastavení v DAW také čtěte až po ověření jednotky a toho, kterého bufferu se týkají. Low Latency Audio

flowchart TB
    accTitle: Čas vypočtený z počtu rámců a celkové zpoždění
    accDescr: 10 ms získaných vydělením 480 rámců číslem 48000 je čas, který představuje buffer, a celkové zpoždění od klávesy po zvuk vznikne po připočtení zpracování v aplikaci, ovladači, zařízení a dalších částech.
    A["480 ÷ 48000"] --> B["10 ms, které představuje buffer"]
    B -->|"přidá se další zpracování"| C["Celkové zpoždění od klávesy po zvuk"]

Obrázek 8: Čas vypočtený z počtu rámců je částí celkového zpoždění.

Porovnání podmínek reprodukce

Nejprve zužte kombinaci, při které se problém projevuje, a k podrobnému záznamu přejděte jen v případě potřeby. Následuje postup pro ověření příčiny, nikoli seznam opatření, v němž se všechny změny nastavení provedou najednou.

Uložte si práci, dokončete důležité schůzky a nahrávání a zkoušejte při hlasitosti, která nezatěžuje sluch. Poznamenejte si původní výstup, vylepšení zvuku, hodnoty bufferu a další nastavení, abyste je mohli vrátit. Položky, pro které nastavení není k dispozici, přeskočte a neměňte registr ani jiná místa jen proto, aby se možnosti nastavení zobrazily.

1. Zvolte stejnou krátkou nahrávku a dobu pozorování a ověřte, zda se problém projevuje za původních podmínek.

   Zaznamenejte verzi Windows, název a verzi aplikace, výstupní zařízení, způsob připojení a verzi ovladače. Poznamenejte si také čas, akci a počet výpadků zvuku. Pokud se problém za původních podmínek neprojeví, nepovažujte to za zlepšení a vraťte se k ověření podmínek, za kterých se projevuje.

2. Z následující tabulky vyberte jedno porovnání a přehrajte nahrávku se změnou pouze této podmínky.

   Porovnávaná podmínka	Co zjistit
   Lokálně uložená nahrávka a přehrávání přes síť	Zda k výpadkům dochází jen při přehrávání přes síť. Pokud se při stejném obsahu liší formát nebo cesta zpracování, zaznamenejte i to.
   Stejná nahrávka v jiné aplikaci	Zda se problém soustředí na konkrétní aplikaci.
   Výstup přes Bluetooth apod. a vestavěný nebo kabelový výstup	Zda se problém soustředí na konkrétní výstupní cestu.
   Vylepšení zvuku zapnutá a vypnutá	Zda se výsledek mění v kombinaci se zpracováním efektů.
   Současný buffer v DAW apod. a hodnota o stupeň vyšší	Zda se něco změní po zvětšení rezervy nashromážděné s předstihem. Zda je přijatelné i zpoždění od akce po zvuk.

3. Pokud porovnáváte vylepšení zvuku, dočasně je pro daný výstup vypněte.

   Ve Windows v části „Nastavení“ → „Systém“ → „Zvuk“ vyberte daný výstup a tam, kde je to k dispozici, vypněte „Vylepšení zvuku“. Pokud se zobrazení nebo dostupnost položek liší, podívejte se do pokynů pro danou verzi a zařízení. Fix distorted or crackling audio in Windows

4. Změněné nastavení vraťte a zkuste to znovu se stejnou nahrávkou a dobou pozorování.

   Výsledky pro „původní podmínky“, „podmínky s jednou změnou“ a „vrácené podmínky“ si postavte vedle sebe. Změnu, která nepomohla, vraťte do původního stavu dřív, než přejdete k dalšímu porovnání. Pokud budete kombinace nastavení měnit pořád dál, nebudete vědět, co vlastně zabralo.

5. Změnu ovladače zkoušejte až po ověření oficiálního zdroje a způsobu obnovení.

   Použijte Windows Update nebo oficiální distribuci výrobce zařízení a zaznamenejte verze a nastavení před změnou a po ní. Předem si ověřte, že se lze vrátit zpět, a u spravovaných počítačů se poraďte se správcem. To, že se zvuk jednou přehraje hned po aktualizaci, ještě neznamená vyřešení; ověřte to za stejných podmínek reprodukce. Fix distorted or crackling audio in Windows

Cílem je záznam, který přiřazuje příznak k podmínkám, například „problém se projevuje v této aplikaci při použití tohoto výstupu“. I když najdete nastavení, které situaci zlepší, oddělte to od určení příčiny.

flowchart TB
    accTitle: Porovnání změnou jedné podmínky a jejím vrácením
    accDescr: Se stejnou nahrávkou se ověří projev problému, změní se jedna podmínka, například aplikace nebo výstup, a zaznamená se i výsledek po vrácení.
    A["Přehrání v původní kombinaci"] --> B["Přehrání po změně jedné podmínky"]
    B --> C["Přehrání po vrácení"]
    C --> D["Zápis podmínek a času výpadků"]

Obrázek 9: Důležitější než jednorázové zlepšení je ověřit, že si podmínky a příznaky opakovaně odpovídají.

Reprodukovatelnost před změnou a po ní

„Podařilo se potlačit příznaky“, „podařilo se zúžit podmínky“ a „podařilo se určit hlavní příčinu“ jsou různé milníky. Závěry zaznamenávejte v rozsahu toho, co se podařilo pozorovat.

flowchart TB
    accTitle: Tři výsledky, které ukazují souvislost s podmínkou
    accDescr: Pokud se problém projeví za původních podmínek, po změně jedné podmínky se situace zlepší a po vrácení se znovu projeví, jde o vodítko ukazující souvislost s danou podmínkou, které se však odděluje od určení příčiny.
    A["Projeví se za původních podmínek"] --> B["Po jedné změně zlepšení"]
    B --> C["Po vrácení se znovu projeví"]
    C --> D["Vodítko souvislosti s podmínkou"]

Obrázek 10: I když nastanou všechny tři výsledky, získáte jen vodítko k souvislosti.

Nízké využití CPU není důkazem, že zvuk stihl své termíny. Zároveň samotný výskyt výpadku neznamená, že hlavní příčinou bylo zpožděné doplňování. Porovnejte nahrávku, zpracování v aplikaci, efekty, výstupní cestu a další prvky a rozhodujte v rozsahu toho, co jste pozorovali. Fix distorted or crackling audio in Windows

Když zavádíte dočasné řešení, zaznamenejte původní nastavení, provedené změny, dobu pozorování, zda se problém vrátil, a přijatelné zpoždění. Pokud hlavní příčina zůstává neurčená, poznamenejte i to.

Záznam výpadků zvuku pomocí WPR

Tento krok provádějte, když samotné porovnání podmínek příčinu nezúží, nebo když potřebujete zkoumat zpracování na straně ovladače. WPR je nástroj pro záznam a WPA nástroj pro analýzu uložené časové osy. Připravte si Windows Performance Toolkit, oprávnění potřebná k záznamu a umístění pro uložení souboru ETL. Pokud máte na spravovaném počítači nainstalovat nástroje a pořídit záznam, požádejte o to správce. Zobrazované názvy a dostupné profily ověřte v nainstalované verzi. Windows Performance Recorder

Soubor ETL může obsahovat názvy procesů, cesty k souborům a další údaje. Před záznamem si ověřte interní pravidla a to, s kým budete záznam sdílet, a nepřikládejte ho beze změn na veřejná místa. Pokud běží jiná relace záznamu, nezastavujte ji svévolně a obraťte se na odpovědnou osobu. WPR How-to Topics

1. Ve WPR otevřete „More Options“ a vyberte profil záznamu vhodný pro daný účel.

   Mezi standardními profily jsou „Audio glitches“ a „CPU usage“. Vyberte nastavení, která umožní zkoumat nespojitosti zvuku a činnost CPU. Dostupné profily, zobrazované názvy a rozsah shromažďovaných dat ověřte v nainstalované verzi a nenastavujte dlouhodobý záznam všech druhů dat. Built-in Recording Profiles

2. Záznam spusťte dříve, než výpadek zvuku reprodukujete.

   Pokud se zobrazí dotaz na zastavení existujícího záznamu, nepokračujte, zrušte spuštění a obraťte se na odpovědnou osobu. Sjednoťte podmínky s průběhem bez záznamu a nevylučujte možnost, že samotná zátěž záznamu příznaky změní. WPR How-to Topics

3. Přehrajte nahrávku za podmínek zjištěných při porovnání a poznamenejte si čas výpadku a provedenou akci.

   Zahrňte i krátké úseky bez problému před příznakem a po něm. U záznamu, ve kterém se problém neprojevil, tuto skutečnost výslovně uveďte a nepovažujte ho za záznam, který zachytil příčinu.

4. Po reprodukci ukončete záznam tlačítkem „Save“ a uložte soubor ETL.

   Tlačítko „Cancel“ záznam neuloží. Poznamenejte si umístění uložení, podmínky reprodukce, zda byl záznam pořízen a zda se zobrazilo varování o ztrátě událostí. U záznamu se ztrátou událostí nepovažujte neviditelné úseky za normální. WPR How-to Topics

Jakmile máte soubor ETL a poznámky s časem, akcemi a podmínkami výpadků, můžete přejít k porovnání ve WPA. Samotné uložení záznamu ještě nezaručuje, že se podařilo zachytit potřebné události. Obsah ověříte v následující části „Běh a čekání kolem výpadku“.

flowchart TB
    accTitle: Krátký záznam, který zahrnuje výpadek zvuku
    accDescr: Ve WPR se spustí záznam, reprodukuje se příznak a poznamená čas, a zastavený a uložený záznam se zkoumá ve WPA.
    A["Spuštění záznamu ve WPR"] --> B["Reprodukce výpadku za stejných podmínek"]
    B --> C["Poznámka času a akce, uložení"]
    C --> D["Přiblížení okolí výpadku ve WPA"]

Obrázek 11: Využití CPU zjištěné až po odeznění příznaku nestačí; je potřeba záznam úseku, kdy se příznak projevil.

Běh a čekání kolem výpadku

Připravte si uložený soubor ETL a poznámky s časem reprodukce. Následuje výchozí bod pro zkoumání ve WPA. Pokud bude potřeba podrobná analýza včetně zásobníků a symbolů, požádejte o ni správce nebo vývojáře a dbejte přitom na správné zacházení se záznamem.

1. Otevřete soubor ETL ve WPA a podle zachycených zvukových událostí a času reprodukce přibližte okolí výpadku.

   Ponechte si pro porovnání i úseky bez příznaků. Nedívejte se jen na žebříček maximálních hodnot, ale porovnávejte data ve stejném časovém rozsahu.

2. Ve stejném rozsahu zkontrolujte „DPC/ISR“ a „CPU Usage (Precise)“.

   Pokud potřebná data chybí, ověřte, zda je profil dokáže zachytit, a vraťte se k záznamu ve WPR. To, že chybí záznam, není totéž, jako že žádný problém nebyl. CPU Analysis, Built-in Recording Profiles

3. Rozlište, zda vlákno související se zvukem bylo připravené k běhu, ale čekalo ve frontě, nebo zda čekalo například na data.

   V prvním případě ověřte, zda na příslušném logickém procesoru dlouho neběžely DPC/ISR nebo jiné rutiny. Ve druhém případě sledujte podle zachycených událostí a zásobníků, co čekání ukončilo. Protože běžící vlákno může být také pozastaveno přerušením, neomezujte se jen na dobu ve stavu Ready a překryjte s ní i úseky DPC/ISR. CPU Analysis

4. Zaznamenejte dohromady časovou souvislost s výpadkem, dotčený procesor a výsledky po změně podmínek.

   Jen podle názvu modulu s dlouhým DPC/ISR neurčujte jako příčinu konkrétní zařízení nebo ovladač. Je možné, že se díváte na vysokou hodnotu z jiného okamžiku nebo na společnou část, kterou prochází více zařízení.

flowchart TB
    accTitle: Zkoumání druhu čekání v úseku výpadku
    accDescr: Přiblíží se okolí výpadku a zkontroluje se stav zvukového vlákna. Pokud bylo připravené a čekalo ve frontě, porovná se s DPC a ISR na stejném CPU; pokud čekalo například na data, sleduje se, co čekání ukončilo.
    A["Přiblížit okolí výpadku"] --> B{"Stav vlákna"}
    B -->|"ve frontě"| C["DPC a ISR"]
    B -->|"čeká na data"| D["Co ukončilo čekání"]

Obrázek 12: Nevybírejte jen maxima, ale čtěte data překrytá s úsekem, kdy bylo zpracování zvuku potřeba.

Pokud příčinu určit nelze, předejte šetření dál jako neuzavřené. Přiložte verze operačního systému, aplikace, zařízení a ovladače, postup reprodukce, výsledky před změnou a po ní, čas výskytu, profil sběru a informaci, zda se objevilo varování o ztrátě událostí. Soubor ETL sdílejte v souladu s interními pravidly pouze s těmi, kdo šetření provádějí.

Předběžné načítání ve zvukových aplikacích

Pokud vyvíjíte vlastní zvukovou aplikaci, navrhněte ji tak, aby plnění dalšího bufferu pokaždé stihlo termín. WASAPI nabízí způsob, jak okamžik, kdy lze buffer zpracovat, dostávat jako událost. Exclusive-Mode Streams

MMCSS je mechanismus, který přiděluje prostředky CPU vláknům multimediálního zpracování s časovými omezeními. Nemá funkce pro předběžnou přípravu dat z disku ani pro odstranění čekání na zámky. I když přidělování přes MMCSS využijete, je zvlášť potřeba návrh, který řeší přípravu dat a omezuje čekání. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Za co MMCSS odpovídá
    accDescr: MMCSS přiděluje prostředky CPU vláknům zpracování s časovými omezeními, ale přípravu dat a omezení čekání na zámky řeší samostatný návrh.
    M["MMCSS: přidělení prostředků CPU"] -.->|"zvlášť potřeba"| D["Příprava dat a méně čekání"]

Obrázek 13: Přidělování prostředků CPU a návrh, díky kterému data dorazí včas, jsou dvě různé úlohy.

Zásadou návrhu je oddělit kód, který čte ze souborů nebo ze sítě, od kódu, který předává zvuk. Přípravu s těžko odhadnutelnou dobou trvání provádějte s předstihem a k předávání používejte předem alokovaný buffer. Na straně zvuku kód uspořádejte tak, aby nemusel čekat na odpověď UI, dlouhé zámky ani synchronní zápis logů.

flowchart TB
    accTitle: Oddělení těžko odhadnutelné přípravy od dodávky zvuku
    accDescr: Návrh, ve kterém se načítání a podobné úlohy provádějí s předstihem a připravená data se předávají zpracování zvuku přes buffer, aby se omezilo dlouhé čekání těsně před termínem.
    A["Předběžná příprava dat"] --> B["Předem alokovaná oblast pro předání"]
    B --> C["Zvuk předá potřebnou část"]
    C --> D["Dodávka na zvukový výstup"]

Obrázek 14: Časově náročnou práci odsuňte z okamžiku těsně před předáním zvuku.

Pokud se připravující strana na delší dobu zastaví, zásoba dojde i přes toto oddělení. Zaznamenávejte způsobem, který nenarušuje zpracování zvuku, nejen průměrnou dobu zpracování, ale i případy dlouhého zpracování nebo čekání a počet neúspěšných dodávek. Skutečně zvolenou velikost bufferu a periodu zjistěte z API nebo ovladače a nepředpokládejte, že zadaná hodnota byla převzata beze změny. Rendering a Stream, Low Latency Audio

Číselné příklady i příklady návrhu slouží k výkladu; nejsou doporučenými hodnotami nastavení pro konkrétní zařízení ani zárukou, že v libovolném prostředí nebude zvuk vypadávat.

Vliv priority reálného času

Obecně nedoporučujeme, aby uživatelé měnili prioritu celého přehrávače na „Reálný čas“. Hrozí narušení dalších důležitých procesů a zvýšení priority běžného vlákna neodstraní čekání způsobené DPC/ISR ani čekání na data a zámky. Při vývoji se používají mechanismy jako MMCSS a návrh, který do dodávky zvuku nezavádí dlouhé čekání. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Čekání, které zůstává i po nastavení priority reálného času
    accDescr: I když přehrávač nastavíte na prioritu reálného času, běžná vlákna nepředběhnou DPC ani ISR na stejném CPU, čekání na data a zámky zůstává a navíc hrozí narušení dalších důležitých procesů.
    A["Přehrávač s prioritou reálného času"] --> B["DPC a ISR nepředběhne"]
    B --> C["Čekání na data a zámky zůstává"]
    C --> D["Riziko narušení jiných procesů"]

Obrázek 15: Ani po zvýšení priority nezmizí čekání, které zdržuje doplňování zvuku.

Související články

• „Plánování procesoru“ ve Windows a nastavení služeb na pozadí
• Bezpečná diagnostika 100% využití disku ve Windows
• Proč je RDP pomalé, i když je připojení rychlé?

Reference

• Microsoft Learn, Rendering a Stream. Dodávání dat do bufferu přehrávání, zbývající množství dat, skutečná velikost bufferu, definice rámce PCM.
• Microsoft Learn, Exclusive-Mode Streams. Časování dodávky do bufferu a zvukové chyby, kompromis se zpožděním, dodávka řízená událostmi. Nejde o obecné doporučení samotného exkluzivního režimu.
• Microsoft Learn, Low Latency Audio. Zvuková cesta ve Windows, buffery, zařízení a zpracování efektů ve vztahu ke zpoždění, kompromisy nízké latence.
• Microsoft Learn, CPU Analysis. Logické procesory, stavy vláken Ready/Waiting, vztah mezi DPC/ISR a během vláken, analýza CPU ve WPA.
• Microsoft Learn, Introduction to DPCs. Mechanismus, který zkracuje obsluhu přerušení a odkládá zbývající práci do DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Dlouhé a časté DPC/ISR, nedostatečná dodávka dat a zvukové chyby. Varovné hodnoty z hodnocení nezobecňujeme jako bezpečnostní kritérium pro všechna zařízení.
• Microsoft Support, Fix distorted or crackling audio in Windows. Kontrola vylepšení zvuku, formátu, ovladačů a dalších položek.
• Microsoft Learn, Windows Performance Recorder. Záznam ETW a analýza ve WPA, použití Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options ve WPR a standardní profily jako Audio glitches a CPU usage.
• Microsoft Learn, WPR How-to Topics. Spuštění záznamu a uložení pomocí Save, konflikty s existujícími relacemi, upozornění na osobní údaje a ztrátu událostí.
• Microsoft Learn, Multimedia Class Scheduler Service. Přidělování prostředků CPU multimediálnímu zpracování s časovými omezeními.
• Microsoft Learn, Scheduling Priorities. Priority procesů a vláken a upozornění týkající se priority reálného času.

Související články

Nejnovější články se stejnými štítky. Prohloubte si znalosti v příbuzných tématech.

Související témata

Stránky s tématy blízkými tomuto článku. Od článku můžete přejít k souvisejícím službám a dalším článkům.

Služby k tomuto tématu

Tento článek navazuje na následující stránky služeb. Vyberte si nejbližší vstup.

Často kladené otázky

Otázky, které se při konzultacích k tématu tohoto článku objevují nejčastěji.

Proč se zvuk přerušuje, když je využití CPU jen kolem 10 %?

Zvuk má svůj termín: další data je nutné doplnit dříve, než se spotřebují data, která se právě přehrávají. I při nízkém využití celého CPU se to nemusí stihnout, pokud se zpracování zvuku v danou chvíli nemůže spustit nebo čeká na potřebná data. Ne všechny výpadky zvuku mají tuto příčinu, a proto je potřeba také porovnání se změněným výstupním zařízením nebo aplikací.

Vyřeší výpadky zvuku zvětšení zvukového bufferu?

Pokud se doplňování zpozdí jen dočasně, větší buffer to někdy dokáže vyrovnat. Prodlouží se však i doba čekání, než se nashromážděný zvuk přehraje. Nejde o nastavení, které by odstranilo trvalý nedostatek výpočetního výkonu nebo odpojování zařízení. U aplikací a ovladačů, které změnu umožňují, si poznamenejte původní hodnotu a porovnávejte vždy po jednom stupni.

Kolik milisekund zvuku představuje 480 rámců při 48 kHz?

Je to 480 ÷ 48000 s, tedy 10 ms. Jeden rámec PCM je jednotka, která sdružuje vzorky všech kanálů ze stejného okamžiku. Tato hodnota je délka zvuku, kterou daný počet rámců představuje, nikoli celkové zpoždění včetně zařízení a aplikací.

Je ovladač s dlouhou dobou běhu DPC nebo ISR viníkem výpadků zvuku?

Může být kandidátem, ale samotné pořadí dob běhu to neprokáže. Porovnejte úsek, kdy došlo k výpadku, s čekáním zvukového vlákna a během DPC/ISR na stejném CPU. Jen podle názvu modulu neprohlašujte za příčinu závadu konkrétního zařízení nebo ovladače a ověřte také výsledky po změně podmínek reprodukce.

Pomůže nastavit přehrávači prioritu reálného času?

Obecně to nedoporučujeme. Ani po zvýšení priority běžného vlákna toto vlákno nepředběhne běžné DPC ani ISR na stejném CPU a nezmizí ani čekání na data nebo zámky. Vývojáři používají mechanismy jako MMCSS a návrh, který nezavádí čekání, a uživatelé nejprve porovnají podmínky reprodukce a výstupní cestu.

O autorovi

Stránka s profilem autora článku.

Go Komura

Zástupce společnosti KomuraSoft LLC

Specializuje se na vývoj softwaru pro Windows, technické konzultace a vyšetřování chyb. Silnou stránkou jsou zakázky, v nichž zůstává stávající software, a vyšetřování poruch s nejasnou příčinou.