Miért szakad meg a hang alacsony CPU-kihasználtság mellett? – A pufferek és a határidők felől nézve

Zenehallgatás közben a hang időnként egy rövid „pattanással” megszakad. A Feladatkezelő szerint a CPU-kihasználtság 10% körül van, mégis egyedül a hang nem stabil. Miért szakad meg ilyenkor a hang, ha a CPU-nak van tartaléka?

Alacsony CPU-kihasználtság mellett is megszakadhat a hang, ha a következő hangadatok utántöltése nem éri el a határidőt. A következő adatokat ugyanis még azalatt kell átadni, amíg a pufferben maradt hang lejátszása tart. Az utántöltés késhet adatra vagy zárra való várakozás, illetve a szükséges logikai processzoron futó DPC/ISR és hasonlók miatt, és ehhez nem kell a teljes CPU-kapacitást kimeríteni. Exclusive-Mode Streams, CPU Analysis

A hallott „pattanás” alapján azonban még nem jelenthető ki, hogy alulcsordulásról van szó. Hasonló tünetet okozhat a hangforrás, az alkalmazás, egy hangeffektus vagy a kimeneti eszköz is. Először ugyanazzal a hangforrással egyenként megváltoztatjuk a feltételeket, majd visszaállítjuk őket, és összehasonlítjuk az eredményt; ha az ok így sem szűkíthető le, a kimaradás előtti és utáni időszakot rögzítjük. Fix distorted or crackling audio in Windows

Ez a cikk ezzel a kérdéssel foglalkozik, valamint az ebből következő kérdésekkel: „Elég nagyobbra állítani a puffert?” és „Mit kell összehasonlítani és mit kell rögzíteni ahhoz, hogy leszűkíthessük az okot?” A cikk nem arra szolgál, hogy pusztán a CPU-kihasználtság vagy a hallott hang alapján megállapítsa egy konkrét hiba okát.

A cikk elsősorban a Windows 11 hangkimenetével foglalkozik. Összehasonlítási alapként a beépített, vezetékes, USB-s, Bluetooth-os és hasonló kimeneteket veszi, zenei produkciós szoftvereknél (DAW) pedig az összehasonlítást arra az esetre is kiterjeszti, amikor az alkalmazás vagy az illesztőprogram kínál pufferbeállítást. A teljes hangrögzítési lánc tervezésére és az egyes eszközök vezeték nélküli kapcsolatának diagnosztikájára nem tér ki teljes körűen.

A magyarázat alappéldája a megosztott mód. A tényleges útvonal, a puffer mérete és a feldolgozási periódus alkalmazásonként, API-nként, illesztőprogramonként és eszközönként eltér, és olyan pufferbeállító képernyő sincs, amely minden alkalmazásban közös lenne. Low Latency Audio

Az itt szereplő CPU-kihasználtság, a 10 ms-nyi hátralévő hanganyag, az utántöltési időpontok és a hasonló értékek szemléltető feltevések. Ezek nem egy adott számítógépen mért reprodukcióról vagy javulásról szóló beszámolók. A cikk második felében leírt műveletek az olvasó saját környezetében elvégzendő ellenőrzési lépések.

A működést a következő, „Hanglejátszási puffer” című szakasztól kezdve sorban olvashatja. A hangkimaradás vizsgálatához szükséges műveletek „A reprodukálási feltételek összehasonlítása” és „A hangkimaradás rögzítése WPR-rel” című szakaszokban találhatók.

Az ábrán a folytonos vonal mindig fennálló kapcsolatot, a szaggatott vonal feltételes kapcsolatot jelöl (a feltételeket a részletoldal kapcsolatonként ismerteti). A kapcsolatok teljes listája (összesen 5, bizonyítékokkal és megbízhatósági szinttel) és a fő fogalmak meghatározása a tudástérkép részletoldalán található (japánul). Adatok: JSON-LD / Turtle

Hanglejátszási puffer

Attól, hogy egy zenefájl el van mentve, a hangszóró még nem szólal meg. Az alkalmazás előkészíti a hangadatokat, és a Windowson és az illesztőprogramon keresztül eljuttatja őket a kimeneti eszközhöz. A hanglejátszási puffer az a terület, amely ideiglenesen tárolja az ezután lejátszandó adatokat. Amíg az eszköz az aktuális adatokat játssza le, az adatokat szolgáltató oldal előkészíti és utántölti a következőket. Rendering a Stream

flowchart TB
    accTitle: A hang egy kis részét előre tárolva játsszuk le
    accDescr: Az előkészített hangadatokkal utántöltjük a puffert, és amíg az eszköz oldalán halad a lejátszás, előkészítjük a következő adatokat.
    A["Következő hang előkészítése"] --> B["Puffer utántöltése"]
    B --> C["A tárolt hang lejátszása"]
    C -.->|"Mielőtt elfogy"| A

1. ábra: A folyamatos lejátszáshoz az utántöltésnek lépést kell tartania a hangot felhasználó oldallal.

Az 1. ábra csak az utántöltés és a felhasználás viszonyát mutató fogalmi ábra. Nem azt ábrázolja, hogy a valódi hangútvonalon lévő több puffer fizikailag egyetlen terület lenne. Low Latency Audio

A puffer feladata, hogy kiegyenlítse a hangot előkészítő és a hangot felhasználó oldal közötti rövid időbeli eltéréseket, és így folyamatos lejátszást tegyen lehetővé. A puffer kapacitása azonban nem azonos azzal, hogy éppen mennyi még le nem játszott adat van benne. Az, hogy „10 ms a kapacitás”, nem jelenti azt, hogy mindig 10 ms-nyi hang van benne. Rendering a Stream

Ebben a cikkben az utántöltés határidejének nevezzük azt az időbeli korlátot, hogy a szükséges következő adatoknak meg kell érkezniük, mielőtt a lejátszás alatt álló adatok elfogynak. A hangfeldolgozásnál az a követelmény, hogy az adat „a megszólalás időpontjáig elkészüljön”. Az, hogy „végül sikerült kiszámolni”, nem elég. Alulcsordulásnak (underrun) nevezzük azt az állapotot, amikor az adatellátás nem ér oda időben, és elfogynak a lejátszandó adatok; ez hangkimaradáshoz vagy kattanó hanghoz vezet. Ha az adatok késve meg is érkeznek, a már hallható megszakadást utólag nem lehet kitölteni. Exclusive-Mode Streams

A hangadatok útja

Szokásos megosztott módban a lejátszóalkalmazás által előkészített adatokat a Windows audiomotorja fogadja, több hangot összekever vagy effektusokat alkalmaz rájuk, majd továbbadja őket az illesztőprogramnak és a kimeneti eszköznek. A lejátszóalkalmazás a hangforrás beolvasásában és a kimenet felé irányuló adatellátásban is részt vesz, az illesztőprogram és a kimeneti eszköz pedig az eszköz oldalára juttatja és lejátssza az adatokat. Low Latency Audio

flowchart TB
    accTitle: A hangadatok útja megosztott módban
    accDescr: A lejátszóalkalmazás által előkészített adatokat az audiomotor keveri és effektusokkal dolgozza fel, majd átadja az illesztőprogramnak, a kimeneti eszköz pedig lejátssza őket.
    A["Lejátszóalkalmazás: adatok előkészítése"] --> E["Audiomotor: keverés, effektusok"]
    E --> D["Illesztőprogram: eszközhöz juttatás"]
    D --> O["Kimeneti eszköz: lejátszás"]

2. ábra: Megosztott módú példa. A köztes feldolgozás és a pufferek API-tól és eszköztől függően változnak.

Az eszköz oldalán is lehet feldolgozás vagy puffer, így a teljes késleltetést nem egyedül az alkalmazás oldali puffer határozza meg. Ez a magyarázat a megosztott mód útvonalát feltételezi, és nem azt jelenti, hogy minden API ugyanazon a feldolgozáson megy keresztül. Low Latency Audio

Utántöltés 10 ms maradéknál

Tegyük fel, hogy a pufferben még 10 ms-nyi le nem játszott adat van. Ha a következő utántöltés 8 ms múlva történik, a lejátszás még a maradék elfogyása előtt folytatódik, de ha az utántöltésre csak 12 ms múlva kerülhet sor, ebben az egyszerűsített példában az adatok a 10 ms-os időpontban elfogynak.

flowchart TB
    accTitle: Ugyanannyi, 10 ms maradéknál is az utántöltés időpontja dönt
    accDescr: Szemléltető feltevésként 10 ms-nyi hátralévő lejátszandó adatnál a 8 ms múlva érkező utántöltés időben van, a 12 ms múlva érkező viszont már az adatok elfogyása után.
    A["10 ms maradt"] --> B{"Következő utántöltés"}
    B -->|"8 ms múlva"| C["Folytonos marad"]
    B -->|"12 ms múlva"| D["10 ms-nál elfogy"]

3. ábra: Egyszerűsített időbeli példa. Nemcsak az számít, hogy sikerült-e utántölteni, hanem az is, hogy mikor.

A CPU-kihasználtság és az utántöltés késése

A CPU-kihasználtság azt mutatja meg, mennyire volt elfoglalt a processzor egy adott időtartam alatt. Ez mást mér, mint azt, hogy a hangfeldolgozás le tudott-e futni abban a pillanatban, amikor szükség volt rá. Ha a CPU-nak egy másodperc nagy részében van is tartaléka, egyetlen olyan 12 ms-os szakasz, amikor nem lehet utántölteni, már elég ahhoz, hogy ez az egyszeri késés megszakítsa a hangot. A később megmaradó feldolgozási tartalékkal az elmúlt lejátszási időpontot nem lehet visszahozni. CPU Analysis

flowchart TB
    accTitle: Átlagos tartalék és egyetlen késő utántöltés
    accDescr: Ha a CPU-nak egy másodperc nagy részében van is tartaléka, egyetlen 12 ms-os szakasz, amikor nem lehet utántölteni, ezzel az egyszeri késéssel megszakíthatja a hangot.
    A["1 mp nagy részében van CPU-tartalék"] --> B["Egyszer 12 ms-ig nincs utántöltés"]
    B --> C["Ez az egy eset megszakítja a hangot"]

4. ábra: Átlagos tartalék mellett sem lehet visszahozni az elmúlt lejátszási időpontot.

A határidőből nemcsak a számítási idő vesz el. Ide tartozik a feldolgozás megkezdéséig tartó várakozás és a szükséges adatok megérkezéséig tartó várakozás is. Ezért a vizsgálat kérdését is átfogalmazzuk: nemcsak az a kérdés, hogy „hány százalékon volt a CPU”, hanem az is, hogy „a hang megszakadásának pillanatában mire várt a következő hang”.

Várakozás adatra és zárra

Tegyük fel, hogy a hangadatokat előkészítő feldolgozás egy fájl beolvasásának befejezésére vár. Ugyanez a helyzet, ha az alkalmazáson belül egy másik feldolgozás által tartott zárra vár. A várakozó feldolgozás maga alig használja a CPU-t, az eszköz oldalán azonban a lejátszás folytatódik, és a hátralévő hang egyre fogy. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: A lejátszás akkor is halad, amikor a várakozás nem használ CPU-t
    accDescr: Amíg a hangfeldolgozás adatra vagy zárra vár, az a feldolgozás nem használ CPU-t, a lejátszás azonban halad, a maradék fogy, és ha késik az utántöltés, a puffer kiürülhet.
    A["A hangfeldolgozás adatra vár"] --> B["Ez nem használ CPU-t"]
    B --> C["Közben halad a lejátszás"]
    C --> D["Késő utántöltésnél kifogy a készlet"]

5. ábra: Az, hogy egy feldolgozás nem használ CPU-t, nem ugyanaz, mint hogy a szükséges munka elkészült.

DPC, ISR és a hangszál

Az ISR az eszközöktől érkező megszakításokat kezelő rutin. A DPC olyan mechanizmus, amely a megszakításkezelés rövidre fogása érdekében a hátralévő munkát későbbre halasztja. A normál DPC-k ugyanazon a logikai processzoron a normál szálak előtt futnak, és amíg egy normál DPC vagy ISR fut, azon a logikai processzoron normál szál nem futhat. Introduction to DPCs, CPU Analysis

Még ha a CPU egészének van is tartaléka, az adatellátás késhet, ha ezek a hangfeldolgozáshoz szükséges processzoron elhúzódnak vagy gyakran előfordulnak. A Microsoft hang- és videoteljesítmény-elemzési dokumentációja a hálózati, tárolási, grafikus és egyéb illesztőprogramok hosszú DPC/ISR-jeit is a hangkimaradás lehetséges okai között említi. Nem biztos, hogy elég csak a hangot kiadó eszközt megvizsgálni. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Amikor az eszközök kiszolgálása késlelteti a hang futását
    accDescr: Ha a hangfeldolgozáshoz szükséges processzoron egy normál DPC vagy ISR elhúzódik, a szál futása késik, ami hatással lehet az utántöltés határidejére.
    A["DPC, ISR ugyanazon a CPU-n"] -->|"Ha elhúzódik"| B["A hang futása várakozik"]
    B --> C["Késik a következő utántöltés"]
    C --> D["Ha elfogy, kimarad a hang"]

6. ábra: A hangot kiadó eszközön kívüli feldolgozás is közvetve befolyásolhatja a hang utántöltését.

Nem húzható meg olyan általános határ, hogy „ha a DPC legfeljebb ennyi mikroszekundum, akkor egyetlen számítógépen sem lesz hangkimaradás”. A teljesítményértékelési dokumentáció figyelmeztetési értékei az adott értékelési feltételekre vonatkoznak, ezért a tényleges utántöltési határidőtől és a puffer tartalékától elszakítva nem tekintjük őket biztonsági küszöbnek. Results for the Streaming Media Performance Assessment

Pufferméret és lejátszási késleltetés

Ha azonos feltételek mellett több hangot tárolunk előre, a puffer könnyebben elnyeli az átmeneti utántöltési késéseket, az újonnan előállított hang viszont a már tárolt hang mögött várakozik. Ami puszta zenehallgatásnál elfogadható várakozás, az billentyűs hangszeren játszva, vagy amikor a mikrofonba mondott és feldolgozott hangunkat saját magunk hallgatjuk vissza, már zavaróvá válik: feltűnik a kezelés és a hang közötti csúszás. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Puffertartalék és késleltetett reakció
    accDescr: Ha több hangot tárolunk előre, a puffer könnyebben elnyeli az átmeneti utántöltési késéseket, de az új hang lejátszásáig tartó várakozás is nő.
    A["Több hang előre tárolása"] --> B["Könnyebben elnyeli a késést"]
    B -->|"Cserébe"| C["Az új hang hátul várakozik"]
    C --> D["Késik a hang a kezeléshez képest"]

7. ábra: A puffer növelése olyan hangolás, amely a reakciósebesség rovására teremt tartalékot.

Nem igaz, hogy „minél kisebb, annál jobb a teljesítmény”, és az sem, hogy „minél nagyobb, annál helyesebb”. A cél az, hogy a szükséges reakciósebesség megmaradjon, és közben elég tartalék legyen a kimaradások elkerüléséhez.

A puffer növelése az átmeneti adatellátási késésekhez teremt tartalékot. Ha már az átlagos adatellátás sem tud lépést tartani a felhasználással, egy véges puffer növelése csak a kiürülésig eltelő időt nyújtja meg, és az eszköz lecsatlakozását sem szünteti meg. Ez nem is annak ajánlása, hogy a kizárólagos mód használata mindent megold. Exclusive-Mode Streams

480 keret 48 kHz-en

A PCM-keret az ugyanabban az időpillanatban lejátszandó összes csatorna mintáit összefogó egység. Attól, hogy sztereó a jel, nem kell a keretszámot megduplázni az idő kiszámításához. A keretszám által képviselt hang hossza a „keretszám ÷ mintavételi frekvencia” képlettel adódik: 48 kHz-en 480 keret 480 ÷ 48000 másodperc, vagyis 10 ms. Ha 48 kHz mellett növeljük a keretszámot, a tárolható hang időtartama is hosszabb lesz. Rendering a Stream

Ez az időtartam nem azonos a billentyű lenyomásától a hang meghallásáig eltelő teljes késleltetéssel. Ehhez ugyanis hozzáadódik az alkalmazás, az illesztőprogram, az eszköz, valamint a többi puffer és feldolgozás ideje is. A DAW beállítási értékeinél is ellenőrizze a mértékegységet és azt, hogy melyik pufferre vonatkoznak. Low Latency Audio

flowchart TB
    accTitle: A keretszámból számolt idő és a teljes késleltetés
    accDescr: A 480 keret 48000-rel való elosztásából adódó 10 ms a puffer által képviselt idő; ehhez hozzáadódik az alkalmazás, az illesztőprogram, az eszköz és más feldolgozások ideje, és ez adja a billentyűtől a hangig tartó teljes késleltetést.
    A["480 ÷ 48000"] --> B["A puffer 10 ms-nyi hangja"]
    B -->|"Más feldolgozás is hozzáadódik"| C["Teljes késés billentyűtől hangig"]

8. ábra: A keretszámból számolt idő csak egy része a teljes késleltetésnek.

A reprodukálási feltételek összehasonlítása

Először azt szűkítjük le, mely kombinációban jelentkezik a hiba, és csak szükség esetén lépünk tovább a részletes rögzítésre. Az alábbi lépések az ok megállapítását szolgálják; ez nem olyan intézkedéslista, amelynek minden beállítás-módosítását egyszerre kellene végrehajtani.

Mentse a munkáját, fejezze be az éles megbeszéléseket és felvételeket, és csak ezután próbálkozzon, a fülnek kíméletes hangerőn. Jegyezze fel az eredeti kimeneti eszközt, a hangkiemelések állapotát, a pufferértékeket és a hasonló beállításokat, hogy vissza tudja állítani őket. Azokat a tételeket, amelyekhez nincs beállítás, hagyja ki, és ne módosítsa a beállításjegyzéket vagy más hasonlót csak azért, hogy egy beállítás megjelenjen.

1. Jelöljön ki egy rövid hangforrást és egy megfigyelési időtartamot, amelyeket végig ugyanúgy használ, és ellenőrizze, hogy az eredeti feltételek mellett jelentkezik-e a hiba.

   Jegyezze fel a Windows verzióját, az alkalmazás nevét és verzióját, a kimeneti eszközt, a csatlakozás módját és az illesztőprogram verzióját. A hangkimaradások időpontját, az akkor végzett műveletet és a kimaradások számát is rögzítse. Ha az eredeti feltételek mellett nem jelentkezik a hiba, ne könyvelje el javulásként, hanem térjen vissza annak vizsgálatához, milyen feltételek mellett jön elő.

2. Válasszon egy összehasonlítást az alábbi táblázatból, és csak azt az egy feltételt megváltoztatva játssza le a hangot.

   Összehasonlított feltétel	Mit vizsgál
   Helyben mentett hangforrás és hálózaton keresztüli lejátszás	Csak hálózati lejátszásnál jelentkezik-e. Ha a tartalom azonos, de a formátum vagy a feldolgozási útvonal eltér, azt is jegyezze fel.
   Ugyanaz a hangforrás egy másik alkalmazásban	Egy adott alkalmazáshoz kötődik-e.
   Bluetooth vagy hasonló kimenet és beépített vagy vezetékes kimenet	Egy adott kimeneti útvonalhoz kötődik-e.
   Hangkiemelések be- és kikapcsolva	Az effektusfeldolgozással való kombináció változtat-e a tüneten.
   DAW vagy hasonló program jelenlegi puffere és egy fokozattal nagyobb érték	Változik-e, ha nagyobb az előre tárolt tartalék. Elfogadható-e a kezeléstől a hangig tartó késés is.

3. Ha a hangkiemeléseket hasonlítja össze, ideiglenesen kapcsolja ki a beállítást az érintett kimeneten.

   A Windows „Gépház” → „Rendszer” → „Hang” lapján válassza ki az érintett kimenetet, és ahol elérhető, kapcsolja ki a „Hangkiemelések” beállítást. Ha a megjelenés eltér, vagy egy elem hiányzik, nézze meg az adott verzióhoz, illetve eszközhöz tartozó útmutatót. Fix distorted or crackling audio in Windows

4. Állítsa vissza a módosított beállítást, és próbálja ki újra ugyanazzal a hangforrással és megfigyelési időtartammal.

   Vesse össze egymás mellett az „eredeti feltételek”, az „egy feltétel módosítva” és a „visszaállított feltételek” eredményét. A hatástalan módosítást állítsa vissza, mielőtt a következő összehasonlításra lép. Ha folyamatosan változtatja a beállítások kombinációját, nem fogja tudni, mi segített.

5. Ha illesztőprogram-módosítást próbál ki, előbb győződjön meg a hivatalos forrásról és a visszaállítás módjáról.

   Használja a Windows Update-et vagy az eszközgyártó hivatalos terjesztési csatornáját, és jegyezze fel a módosítás előtti és utáni verziót és beállításokat. Előre ellenőrizze, hogy vissza tudja-e állítani az eredeti állapotot, felügyelt számítógépen pedig egyeztessen a rendszergazdával. Attól, hogy a frissítés után egyszer sikerült lejátszani a hangot, még ne tekintse megoldottnak a problémát; ellenőrizze ugyanazokkal a reprodukálási feltételekkel. Fix distorted or crackling audio in Windows

A cél egy olyan feljegyzés, amely a tünetet a feltételekhez rendeli, például: „ezzel az alkalmazással, ezt a kimenetet használva jelentkezik”. Ha talál olyan beállítást, amellyel javul a helyzet, azt is tartsa külön az ok megállapításától.

flowchart TB
    accTitle: Összehasonlítás egy feltétel módosításával és visszaállításával
    accDescr: Ugyanazzal a hangforrással ellenőrizzük a hiba jelentkezését, megváltoztatunk egy feltételt, például az alkalmazást vagy a kimenetet, és a visszaállítás utáni eredményt is feljegyezzük.
    A["Lejátszás az eredeti kombinációval"] --> B["Lejátszás egy feltétel módosításával"]
    B --> C["Lejátszás visszaállítás után"]
    C --> D["Kimaradás feltételeinek és idejének feljegyzése"]

9. ábra: Az egyszeri javulásnál fontosabb annak ellenőrzése, hogy a feltételek és a tünetek ismételten összefüggenek-e.

Reprodukálhatóság a módosítás előtt és után

„Sikerült elnyomni a tünetet”, „sikerült leszűkíteni a feltételeket” és „sikerült azonosítani a kiváltó okot” – ezek különböző eredmények. A következtetést annak megfelelően rögzítse, ameddig a megfigyelései terjednek.

flowchart TB
    accTitle: Három eredmény, amely a feltétellel való összefüggésre utal
    accDescr: Ha a hiba az eredeti feltételekkel jelentkezik, egy feltétel módosításával javul, visszaállítva pedig újra jelentkezik, az az adott feltétellel való összefüggésre utaló nyom, de ezt külön kell kezelni az ok megállapításától.
    A["Eredeti feltétellel jelentkezik"] --> B["Egy módosítással javul"]
    B --> C["Visszaállítva újra jelentkezik"]
    C --> D["Nyom az összefüggésre"]

10. ábra: Ha mindhárom teljesül is, csak az összefüggésre utaló nyomig jutunk.

Az alacsony CPU-kihasználtság nem bizonyítja, hogy a hang határidejét sikerült tartani. Ugyanakkor pusztán abból, hogy volt hangkimaradás, az sem állítható, hogy a késő utántöltés volt a kiváltó ok. Hasonlítsa össze a hangforrást, az alkalmazás feldolgozását, az effektusokat, a kimeneti útvonalat és a többi tényezőt, és a megfigyelt körön belül vonjon le következtetést. Fix distorted or crackling audio in Windows

Ha ideiglenes kerülő megoldást alkalmaz, jegyezze fel az eredeti beállítást, a módosítás tartalmát, a megfigyelési időtartamot, azt, hogy újra jelentkezett-e a hiba, és az elfogadható késleltetést. Ha a kiváltó ok még nem tisztázott, ezt is rögzítse.

A hangkimaradás rögzítése WPR-rel

Erre akkor van szükség, ha a feltételek összehasonlításával nem sikerül leszűkíteni az okot, vagy ha az illesztőprogram oldali feldolgozást kell megvizsgálni. A WPR a rögzítésre, a WPA a mentett idővonal elemzésére szolgáló eszköz. Készítse elő a Windows Performance Toolkitet, a rögzítéshez szükséges jogosultságokat és az ETL-fájl mentési helyét. Ha felügyelt számítógépen kell telepíteni az eszközöket és rögzíteni, kérje a rendszergazda segítségét. A megjelenített neveket és az elérhető profilokat a telepített verzióban ellenőrizze. Windows Performance Recorder

Az ETL-fájl tartalmazhat folyamatneveket, fájlelérési utakat és hasonló adatokat. A rögzítés előtt tisztázza a belső szabályokat és azt, hogy kivel osztja meg a fájlt, és ne csatolja változtatás nélkül nyilvános helyen. Ha egy másik rögzítési munkamenet már fut, ne állítsa le önhatalmúlag, hanem egyeztessen a felelőssel. WPR How-to Topics

1. Nyissa meg a WPR „More Options” részét, és válassza ki a célnak megfelelő rögzítési profilt.

   A beépített profilok között megtalálható az „Audio glitches” és a „CPU usage”. Olyan beállítást válasszon, amellyel a hang folytonossági hibái és a CPU működése is vizsgálható. Az elérhető profilokat, a megjelenített neveket és a gyűjtött adatokat a telepített verzióban ellenőrizze, és ne állítsa be, hogy hosszú ideig minden típust rögzítsen. Built-in Recording Profiles

2. A rögzítést még a hangkimaradás előidézése előtt indítsa el.

   Ha megerősítő kérdés jelenik meg egy meglévő rögzítés leállításáról, ne lépjen tovább, hanem vonja vissza az indítást, és egyeztessen a felelőssel. A feltételeket igazítsa a rögzítés nélküli esethez, és vegye számításba, hogy maga a rögzítés okozta terhelés is megváltoztathatja a tünetet. WPR How-to Topics

3. Játssza le a hangot az összehasonlítás során talált feltételekkel, és jegyezze fel a kimaradás időpontját és az akkor végzett műveletet.

   A tünet előtt és után rögzítsen egy rövid hibamentes szakaszt is. Ha a hiba nem jelentkezett a rögzítés alatt, ezt egyértelműen jelölje, és ne kezelje az ilyen felvételt úgy, mintha megörökítette volna az okot.

4. A hiba jelentkezése után a „Save” gombbal fejezze be a rögzítést, és mentse az ETL-fájlt.

   A „Cancel” gombbal a rögzítés nem mentődik. Jegyezze fel a mentési helyet, a reprodukálási feltételeket, azt, hogy készült-e rögzítés, és azt, hogy volt-e figyelmeztetés eseményvesztésről. Hiányos rögzítés esetén a nem látható szakaszokat ne ítélje normálisnak. WPR How-to Topics

Ha megvan az ETL-fájl és a kimaradás időpontjáról, a műveletről és a feltételekről készült jegyzet, készen áll a WPA-ban végzett összevetésre. Abból, hogy a rögzítést mentette, még nem következik, hogy a szükséges események is rögzítésre kerültek. A tartalmat a következő, „Futás és várakozás a kimaradás körül” című szakasz szerint ellenőrizze.

flowchart TB
    accTitle: Rövid rögzítés, amely tartalmazza a kimaradást
    accDescr: A WPR-rel elindítjuk a rögzítést, előidézzük a tünetet és feljegyezzük az időpontját, majd a leállított és mentett rögzítést a WPA-ban vizsgáljuk meg.
    A["Rögzítés indítása WPR-rel"] --> B["Kimaradás előidézése azonos feltételekkel"]
    B --> C["Idő és művelet feljegyzése, mentés"]
    C --> D["A környező szakasz nagyítása WPA-ban"]

11. ábra: A tünet elmúltával megnézett CPU-kihasználtság nem elég; a tünet idejéről készült rögzítésre van szükség.

Futás és várakozás a kimaradás körül

Készítse elő a mentett ETL-fájlt és a hiba jelentkezésének időpontjáról készült jegyzetet. Az alábbiak a WPA-ban végzett vizsgálat kiindulópontjai. Ha hívási vermeket és szimbólumokat is igénylő részletes elemzésre van szükség, a rögzítés kezelésére ügyelve forduljon a rendszergazdához vagy a fejlesztőkhöz.

1. Nyissa meg az ETL-fájlt a WPA-ban, és a rögzített hangesemények, valamint a hiba jelentkezésének időpontja alapján nagyítsa ki a kimaradás előtti és utáni szakaszt.

   Összehasonlításképpen hagyjon a nézetben tünetmentes szakaszt is. Ne csak a maximális értékek rangsorát nézze, hanem azonos időtartományra igazítva hasonlítson össze.

2. Ugyanebben a tartományban nézze meg a „DPC/ISR” és a „CPU Usage (Precise)” adatait.

   Ha a szükséges adatok hiányoznak, ellenőrizze, hogy a profil gyűjti-e őket, és térjen vissza a WPR-es rögzítéshez. Az, hogy valamiről nincs adat, nem ugyanaz, mint hogy nem volt probléma. CPU Analysis, Built-in Recording Profiles

3. Különítse el, hogy a hanggal kapcsolatos szál futásra készen a sorára várt-e, vagy adatra vagy más egyébre várakozott.

   Az első esetben vesse össze, nem futott-e sokáig DPC/ISR vagy hasonló az érintett logikai processzoron. A második esetben a rögzített események és hívási vermek alapján kövesse nyomon, mi oldotta fel a várakozást. Mivel egy futó szálat is megszakíthat egy megszakítás, ne csak a Ready állapotban töltött időre szűkítsen, hanem vetítse rá a DPC/ISR-szakaszokat is. CPU Analysis

4. Rögzítse együtt a kimaradással való időbeli egyezést, az érintett processzort és a feltételek módosításának eredményét.

   Pusztán egy hosszú DPC/ISR modulneve alapján ne nyilvánítson egy adott eszközt vagy illesztőprogramot okozónak. Előfordulhat, hogy egy másik időpontban mért nagy értéket, vagy egy több eszköz által közösen használt komponenst lát.

flowchart TB
    accTitle: A várakozás módjának vizsgálata a kimaradás szakaszában
    accDescr: Kinagyítjuk a kimaradás körüli szakaszt, és megnézzük a hangszál állapotát. Ha futásra készen a sorára várt, összevetjük az ugyanazon a processzoron futó DPC-kkel és ISR-ekkel; ha adatra vagy hasonlóra várt, nyomon követjük, mi oldotta fel a várakozást.
    A["Kimaradás körüli szakasz nagyítása"] --> B{"Szál állapota"}
    B -->|"Sorára vár"| C["DPC, ISR"]
    B -->|"Adatra vár"| D["A várakozást feloldó művelet"]

12. ábra: Ne csak a maximumokat szedje ki, hanem vesse össze őket azzal a szakasszal, amikor a hangfeldolgozásnak futnia kellett.

Ha az ok nem azonosítható, adja át a vizsgálatot tisztázatlanként. Mellékelje az operációs rendszer, az alkalmazás, az eszköz és az illesztőprogram verzióját, a reprodukálás lépéseit, a módosítás előtti és utáni eredményeket, a kimaradás időpontját, a használt gyűjtési profilt, valamint azt, hogy volt-e figyelmeztetés eseményvesztésről. Az ETL-fájlt a belső szabályoknak megfelelően csak a vizsgálatért felelős személlyel ossza meg.

Előzetes betöltés hangalkalmazásokban

Ha saját hangalkalmazást fejleszt, úgy tervezze meg, hogy a következő puffert feltöltő feldolgozás minden alkalommal tartsa a határidőt. A WASAPI lehetőséget ad arra, hogy az alkalmazás eseményen keresztül kapja meg, mikor dolgozhatja fel a puffert. Exclusive-Mode Streams

Az MMCSS olyan mechanizmus, amely CPU-erőforrásokat oszt ki az időkorlátos multimédiás feldolgozást végző szálaknak. Arra nem képes, hogy az adatokat előre beolvassa a lemezről, vagy megszüntesse a zárra való várakozást. Az MMCSS-alapú erőforrás-elosztás használata mellett is külön tervezés kell az adatok előkészítéséhez és a várakozások csökkentéséhez. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Amiért az MMCSS felel
    accDescr: Az MMCSS CPU-erőforrásokat oszt ki az időkorlátos feldolgozás szálainak, az adatok előkészítését és a zárra való várakozás csökkentését azonban külön tervezéssel kell megoldani.
    M["MMCSS: CPU-erőforrás kiosztása"] -.->|"Külön kell"| D["Adat-előkészítés, kevesebb várakozás"]

13. ábra: A CPU-erőforrások kiosztása és az adatok időbeni rendelkezésre állását biztosító tervezés két külön feladat.

A tervezési elv az, hogy a fájlból vagy hálózatról olvasó feldolgozást különválasszuk a hangot átadó feldolgozástól. A nehezen kiszámítható idejű előkészítést előre végezzük el, az átadáshoz pedig előre lefoglalt puffert használunk. A hangoldalt úgy alakítjuk ki, hogy ne kelljen a felhasználói felület válaszára, hosszan tartott zárra vagy szinkron naplóírásra várnia.

flowchart TB
    accTitle: A nehezen kiszámítható előkészítés és a hangellátás szétválasztása
    accDescr: Olyan felépítés, amelyben a beolvasás és a hasonló műveletek előre lezajlanak, az előkészített adatok pufferen keresztül jutnak a hangfeldolgozáshoz, így kevesebb a hosszú várakozás közvetlenül a határidő előtt.
    A["Adatok előkészítése előre"] --> B["Előre lefoglalt átadási terület"]
    B --> C["A hangfeldolgozás átadja a szükséges részt"]
    C --> D["Ellátás a hangkimenet felé"]

14. ábra: A hosszadalmas munkát kivesszük a hangátadás előtti közvetlen időszakból.

Ha az előkészítő oldal hosszabb időre leáll, a készlet ilyen szétválasztás mellett is kifogy. Ne csak az átlagos feldolgozási időt rögzítse, hanem azokat az eseteket is, amikor hosszú feldolgozás vagy várakozás fordult elő, és azt is, hányszor nem sikerült adatot szolgáltatni, mégpedig olyan módszerrel, amely nem zavarja a hangfeldolgozást. A ténylegesen kiválasztott pufferméretet és periódust az API-tól vagy az illesztőprogramtól kérdezze le, és ne feltételezze, hogy a megadott érték változatlanul érvényesült. Rendering a Stream, Low Latency Audio

A számpéldák és a tervezési példák is szemléltető jellegűek; nem egy adott eszközre ajánlott beállítási értékek, és nem garantálják, hogy tetszőleges környezetben ne legyen hangkimaradás.

A valós idejű prioritás hatása

Nem ajánljuk általánosságban, hogy a felhasználó a teljes lejátszóprogramot „Valós idejű” prioritásra állítsa. Ez más fontos feldolgozásokat akadályozhat, és a normál szálprioritás emelése sem szünteti meg a DPC/ISR miatti, illetve az adatra vagy zárra való várakozást. Fejlesztéskor az MMCSS-hez hasonló mechanizmusokra és olyan tervezésre támaszkodunk, amely nem visz hosszú várakozást a hangellátásba. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Várakozások, amelyek valós idejű prioritás mellett is megmaradnak
    accDescr: Ha a lejátszót valós idejű prioritásra állítjuk, a normál szálak akkor sem előzhetik meg az ugyanazon a processzoron futó DPC-ket és ISR-eket, az adatra és zárra való várakozás is megmarad, ráadásul fennáll a veszélye, hogy más fontos feldolgozásokat akadályoz.
    A["Lejátszó valós idejű prioritásra"] --> B["DPC, ISR nem előzhető meg"]
    B --> C["Adat- és zárvárakozás megmarad"]
    C --> D["Más feldolgozást akadályozhat"]

15. ábra: A prioritás emelése után is megmaradnak a hang utántöltését késleltető várakozások.

Kapcsolódó cikkek

• A Windows „Processzorütemezés” beállítása és a háttérszolgáltatások
• A Windows 100%-os lemezhasználatának biztonságos behatárolása
• Miért lassú az RDP, ha gyors a hálózat?

Források

• Microsoft Learn, Rendering a Stream. A lejátszási puffer adatellátása, a hátralévő adatmennyiség, a tényleges pufferméret és a PCM-keret definíciója.
• Microsoft Learn, Exclusive-Mode Streams. A pufferellátás időzítése és a hangakadások, egyensúlyozás a késleltetéssel, eseményvezérelt adatellátás. A hivatkozás nem jelenti magának a kizárólagos módnak az általános ajánlását.
• Microsoft Learn, Low Latency Audio. A Windows hangútvonala, a pufferek, az eszközök és az effektusfeldolgozás összefüggése a késleltetéssel, az alacsony késleltetés kompromisszumai.
• Microsoft Learn, CPU Analysis. Logikai processzorok, a szálak Ready/Waiting állapota, a DPC/ISR és a szálfuttatás kapcsolata, CPU-elemzés a WPA-ban.
• Microsoft Learn, Introduction to DPCs. A megszakításkezelés rövidre fogásának és a hátralévő munka DPC-be halasztásának mechanizmusa.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Hosszú és gyakori DPC/ISR-ek, elégtelen adatellátás és hangakadások. Az értékelés figyelmeztetési értékeit nem általánosítjuk minden eszközre érvényes biztonsági küszöbbé.
• Microsoft Support, Fix distorted or crackling audio in Windows. A hangkiemelések, a formátum, az illesztőprogramok és más tényezők ellenőrzése.
• Microsoft Learn, Windows Performance Recorder. ETW-alapú rögzítés és elemzés a WPA-val, a Windows Performance Toolkit használata.
• Microsoft Learn, Built-in Recording Profiles. A WPR More Options része, valamint az Audio glitches, a CPU usage és más beépített profilok.
• Microsoft Learn, WPR How-to Topics. A rögzítés indítása és mentése a Save gombbal, ütközés meglévő munkamenetekkel, figyelmeztetések a személyes adatokról és az eseményvesztésről.
• Microsoft Learn, Multimedia Class Scheduler Service. CPU-erőforrások kiosztása az időkorlátos multimédiás feldolgozásnak.
• Microsoft Learn, Scheduling Priorities. Folyamat- és szálprioritások, valamint a valós idejű prioritással kapcsolatos figyelmeztetések.

Kapcsolódó cikkek

Azonos címkéket használó, legfrissebb cikkek. Mélyítse el ismereteit szorosan kapcsolódó témákban.

Kapcsolódó témák

Ehhez a témához közel álló témaoldalak. A cikkből kiindulva eljuthat a kapcsolódó szolgáltatásokhoz és további cikkekhez.

Mely szolgáltatásokhoz kapcsolódik ez a téma

Ez a cikk a következő szolgáltatási oldalakhoz kapcsolódik. Kezdje azzal, amelyik a leginkább illik az Ön helyzetéhez.

Gyakori kérdések

A cikk témájával kapcsolatban a konzultációk során gyakran felmerülő kérdések.

Miért szakad meg a hang, ha a CPU-kihasználtság csak 10% körül van?

A hangnak határideje van: a következő adatokat azelőtt kell utántölteni, hogy a lejátszás alatt álló adatok elfogynának. Még ha a CPU teljes kihasználtsága alacsony is, az utántöltés lekésheti ezt a határidőt, ha a hangfeldolgozás abban a pillanatban nem tudott futni, vagy a szükséges adatokra várt. Nem minden hangkimaradás ered ebből, ezért a kimeneti eszköz és az alkalmazás cseréjével végzett összehasonlításra is szükség van.

Megszűnik a hangkimaradás, ha nagyobbra állítom a hangpuffert?

Ha az utántöltés csak átmenetileg késik, egy nagyobb puffer elnyelheti a késést. Ugyanakkor a tárolt hang lejátszásáig tartó várakozás is nő. Ez a beállítás nem szünteti meg a tartósan elégtelen feldolgozási kapacitást vagy az eszköz lecsatlakozását. Azoknál az alkalmazásoknál és illesztőprogramoknál, ahol az érték módosítható, jegyezze fel az eredeti értéket, és fokozatonként hasonlítson össze.

Hány milliszekundumnyi hangnak felel meg 480 keret 48 kHz-en?

480 ÷ 48000 másodperc, vagyis 10 ms. Egy PCM-keret az ugyanahhoz az időponthoz tartozó összes csatorna mintáit összefogó egység. Ez az érték az adott keretszám által képviselt hang hossza, nem pedig az eszközöket és az alkalmazásokat is magában foglaló teljes késleltetés.

A hosszú DPC- vagy ISR-futásidejű illesztőprogram okozza a hangkimaradást?

Lehetséges ok, de pusztán a futásidők rangsora alapján nem állapítható meg. Vesse össze a kimaradás szakaszát, a hangszál várakozását és az ugyanazon a processzoron futó DPC/ISR-eket. Ne jelentse ki pusztán a modulnév alapján, hogy egy adott eszköz vagy illesztőprogram hibás, és ellenőrizze a reprodukálási feltételek módosításának eredményét is.

Javít a helyzeten, ha a lejátszót valós idejű prioritásra állítom?

Általánosságban nem ajánljuk. Egy normál szál prioritásának emelése után a szál továbbra sem előzheti meg az ugyanazon a processzoron futó normál DPC-ket és ISR-eket, és az adatra vagy zárra való várakozás sem szűnik meg. A fejlesztők az MMCSS-hez hasonló mechanizmusokat és várakozást be nem vivő tervezést alkalmaznak, a felhasználók pedig először a reprodukálási feltételeket és a kimeneti útvonalat hasonlítják össze.

A szerző bemutatása

A cikk szerzőjének bemutatkozó oldala.

Go Komura

A KomuraSoft LLC képviselője

Fő területei a Windows-szoftverfejlesztés, a műszaki konzultáció és a hibakeresés; különösen a meglévő megoldásokat érintő projektekben, valamint a nehezen felderíthető okú hibák kivizsgálásában erős.