Varför hackar ljudet fast CPU-användningen är låg? – Utifrån buffertar och tidsgränser

Du lyssnar på musik och då och då bryts ljudet med ett ”knäpp”. Aktivitetshanteraren visar en CPU-användning på runt 10 %, men det är bara ljudet som inte är stabilt. Varför hackar ljudet i ett sådant läge, trots att processorn har kapacitet över?

Även om CPU-användningen är låg kan ljudet brytas om påfyllningen av nästa ljuddata inte hinner klart före tidsgränsen. Det beror på att nästa data måste lämnas över medan det ljud som finns kvar i bufferten spelas upp. Fördröjd påfyllning på grund av väntan på data eller lås, DPC/ISR på den logiska processor som behövs med mera inträffar även utan att hela processorn används fullt ut. Exclusive-Mode Streams, CPU Analysis

Ett hörbart ”knäpp” räcker dock inte för att slå fast att det rör sig om en buffertunderskridning (underrun). Liknande symtom uppstår också på grund av ljudkällan, appen, ljudeffekter, utdataenheten med mera. Vi börjar med att jämföra med samma ljudkälla, ändra ett villkor i taget och sedan återställa det, och om det inte räcker för att ringa in orsaken spelar vi in vad som händer före och efter ljudbortfallet. Fix distorted or crackling audio in Windows

Den här artikeln behandlar den frågan och de följdfrågor som kommer efter den: ”räcker det att göra bufferten större?” och ”vad ska jämföras och vad ska spelas in för att ringa in orsaken?”. Artikeln fastställer inte orsaken till enskilda fel enbart utifrån CPU-användningen eller det ljud man hör.

Fokus ligger främst på ljudutmatning i Windows 11. Vi jämför inbyggda, trådbundna, USB-, Bluetooth- och andra utgångar, och för musikproduktionsprogram (DAW) behandlar vi också jämförelser när appen eller drivrutinen erbjuder buffertinställningar. Design av hela inspelningskedjan och diagnostik av trådlös kommunikation för varje enhet behandlas inte uttömmande.

I förklaringen använder vi delat läge som grundexempel. Den faktiska vägen, buffertstorleken och bearbetningsperioden skiljer sig mellan appar, API:er, drivrutiner och enheter, och det finns ingen skärm för buffertinställningar som är gemensam för alla appar. Low Latency Audio

CPU-användningen, de 10 millisekunderna som återstår, påfyllningstidpunkterna och liknande som anges här är antaganden i förklarande syfte. De är inga rapporter om uppmätt reproduktion eller förbättring på en viss dator. Åtgärderna i artikelns senare del är kontrollsteg som du utför i din egen miljö.

Mekanismen kan läsas i ordning med början i nästa avsnitt, ”Ljuduppspelningsbufferten”. Åtgärderna för att undersöka ljudbortfall finns i ”Jämför reproduktionsvillkor” och ”Spela in ljudbortfall med WPR”.

I diagrammet markerar en heldragen linje en relation som alltid gäller och en streckad linje en villkorad relation (villkoren anges per relation på detaljsidan). Den fullständiga listan över relationer (totalt 5, med belägg och säkerhetsgrad) och definitionerna av huvudbegreppen finns samlade på detaljsidan för kunskapskartan (på japanska). Data: JSON-LD / Turtle

Ljuduppspelningsbufferten

Det räcker inte att spara en musikfil för att högtalarna ska låta. Appen förbereder ljuddata och levererar dem via Windows och drivrutinen till utdataenheten. Ljuduppspelningsbufferten är ett område där data som ska spelas upp härnäst lagras tillfälligt. Medan enheten spelar upp aktuella data förbereder den levererande sidan nästa data och fyller på med dem. Rendering a Stream

flowchart TB
    accTitle: Ljudet buffras en bit i förväg och spelas sedan upp
    accDescr: Förberedda ljuddata fylls på i bufferten, och nästa data förbereds medan uppspelningen på enhetssidan fortsätter.
    A["Förbered nästa ljud"] --> B["Fyll på bufferten"]
    B --> C["Spela upp buffrat ljud"]
    C -.->|"innan det tar slut"| A

Figur 1: För att uppspelningen ska fortsätta måste påfyllningen hålla jämna steg med den sida som använder ljudet.

Figur 1 är en konceptuell bild som bara visar förhållandet mellan påfyllning och förbrukning. Den betraktar inte de flera buffertarna längs den faktiska ljudvägen som ett enda fysiskt område. Low Latency Audio

Buffertens uppgift är att jämna ut korta tidsskillnader mellan den sida som förbereder ljudet och den sida som använder det, så att uppspelningen blir sammanhängande. Buffertens kapacitet och mängden ännu inte uppspelade data som finns i den just nu är dock två olika saker. Att ”kapaciteten är 10 millisekunder” betyder inte att det alltid finns 10 millisekunder kvar. Rendering a Stream

Här kallar vi den tidsmässiga begränsningen att nästa data som behövs ska levereras innan de data som spelas upp tar slut för tidsgränsen för påfyllning. Ljudbearbetning kräver att data ”blev klara till uppspelningstidpunkten”. Det räcker inte att ”beräkningen till slut blev klar”. Tillståndet där leveransen inte hinner fram och data att spela upp tar slut är en buffertunderskridning, som leder till ljudbortfall eller klickljud. Även om data kommer fram senare går det inte att i efterhand fylla igen ett glapp som redan har hörts. Exclusive-Mode Streams

Ljuddatans väg

I vanligt delat läge tar Windows ljudmotor emot de data som uppspelningsappen har förberett, mixar flera ljud eller lägger på effekter och skickar dem sedan vidare till drivrutinen och utdataenheten. Uppspelningsappen är inblandad både i att läsa in ljudkällan och i att leverera till utgången, medan drivrutinen och utdataenheten transporterar data till enhetssidan och spelar upp dem. Low Latency Audio

flowchart TB
    accTitle: Ljuddatans väg i delat läge
    accDescr: Data som uppspelningsappen har förberett mixas och effektbearbetas av ljudmotorn, som skickar dem till drivrutinen, och utdataenheten spelar upp dem.
    A["Uppspelningsapp: förbereder data"] --> E["Ljudmotor: mixning, effekter"]
    E --> D["Drivrutin: för till enheten"]
    D --> O["Utdataenhet: uppspelning"]

Figur 2: Ett exempel i delat läge. Bearbetningen och buffertarna på vägen varierar med API och enhet.

Det kan också finnas bearbetning och buffertar på enhetssidan, så den totala latensen avgörs inte enbart av appens buffert. Förklaringen utgår från vägen i delat läge och betyder inte att alla API:er går igenom samma bearbetning. Low Latency Audio

Påfyllning med 10 millisekunder kvar

Anta att det just nu finns 10 millisekunder ouppspelade data kvar i bufferten. Kommer nästa påfyllning efter 8 millisekunder fortsätter uppspelningen medan det fortfarande finns data kvar, men om det inte går att fylla på förrän efter 12 millisekunder tar data slut vid 10 millisekunder i det här förenklade exemplet.

flowchart TB
    accTitle: Med samma 10 millisekunder kvar avgör påfyllningstiden resultatet
    accDescr: Som ett antagande för förklaringen visar bilden att med 10 millisekunder uppspelningsdata kvar hinner en påfyllning efter 8 millisekunder fram, medan en efter 12 millisekunder kommer först när data redan är slut.
    A["10 millisekunder kvar"] --> B{"Nästa påfyllning"}
    B -->|"efter 8 ms"| C["Fortsätter"]
    B -->|"efter 12 ms"| D["Slut vid 10 ms"]

Figur 3: Ett tidsmässigt förenklat exempel. Det viktiga är inte bara om påfyllningen lyckades, utan också när den lyckades.

CPU-användning och fördröjd påfyllning

CPU-användningen visar hur upptagen processorn är under en viss tidsperiod. Den mäter något annat än om ljudbearbetningen kunde köras i exakt det ögonblick då den behövdes. Även om processorn har kapacitet över under större delen av en sekund kan ljudet brytas om det finns ett enda intervall på 12 millisekunder då påfyllning inte går – den enda fördröjningen räcker. Den kapacitet som blir över efteråt kan inte ta igen en uppspelningstidpunkt som redan har passerat. CPU Analysis

flowchart TB
    accTitle: Marginal i genomsnitt och en enda fördröjd påfyllning
    accDescr: Även om processorn har kapacitet över under större delen av en sekund kan ljudet brytas av den enda fördröjningen om det finns ett intervall på 12 millisekunder då påfyllning inte går.
    A["CPU:n ledig större delen av sekunden"] --> B["En gång 12 ms utan påfyllning"]
    B --> C["Den gången bryts ljudet"]

Figur 4: Även med marginal i genomsnitt går en passerad uppspelningstidpunkt inte att ta igen.

Det är inte bara beräkningstiden som tar av tiden fram till tidsgränsen. Även väntan innan bearbetningen kan börja och väntan tills nödvändiga data har kommit fram räknas in. Därför ändrar vi också frågan vid undersökningen, från enbart ”hur många procent låg CPU:n på?” till ”vad väntade nästa ljud på i det ögonblick ljudet bröts?”.

Väntan på data och lås

Anta att den bearbetning som förbereder ljuddata väntar på att en filinläsning ska bli klar. Detsamma gäller om den väntar på ett lås som en annan del av appen håller. Den väntande bearbetningen använder själv inte mycket processorkraft, men på enhetssidan fortsätter uppspelningen och det kvarvarande ljudet minskar. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Uppspelningen fortsätter även under väntan som inte använder CPU
    accDescr: När ljudbearbetningen väntar på data eller lås använder den inte processorn, men uppspelningen går vidare och det som finns kvar minskar; om påfyllningen försenas kan bufferten ta slut.
    A["Ljudbearbetningen väntar på data"] --> B["Den använder inte CPU:n"]
    B --> C["Uppspelningen fortsätter ändå"]
    C --> D["Sen påfyllning tömmer lagret"]

Figur 5: Att processorn inte används är inte detsamma som att det nödvändiga arbetet är klart.

DPC, ISR och ljudtråden

ISR är den bearbetning som hanterar avbrott från enheter. DPC är en mekanism som skjuter upp resten av arbetet till senare för att hålla avbrottshanteringen kort. En vanlig DPC körs före vanliga trådar på samma logiska processor, och medan en vanlig DPC eller ISR körs kan den logiska processorn inte köra vanliga trådar. Introduction to DPCs, CPU Analysis

Även om processorn som helhet har marginal kan leveransen försenas om dessa drar ut på tiden eller inträffar ofta på den processor som ljudbearbetningen behöver. I Microsofts material om prestandaanalys för ljud och video anges även långa DPC/ISR från drivrutiner för nätverk, lagring, grafik och annat som möjliga orsaker till ljudbortfall. Det räcker inte alltid att bara undersöka den enhet som spelar upp ljudet. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: När svar till enheter fördröjer ljudets körning
    accDescr: Om vanliga DPC:er eller ISR:er drar ut på tiden på den processor som ljudbearbetningen behöver försenas trådens körning, vilket kan påverka tidsgränsen för påfyllning.
    A["DPC/ISR på samma CPU"] -->|"om de drar ut"| B["Ljudets körning får vänta"]
    B --> C["Påfyllning av nästa ljud försenas"]
    C --> D["När resten tar slut bryts ljudet"]

Figur 6: Även bearbetning utanför den enhet som spelar upp ljudet kan indirekt påverka påfyllningen av ljud.

Det går inte att dra en gemensam gräns som ”om DPC:er håller sig under så och så många mikrosekunder hackar ljudet aldrig på någon dator”. Varningsvärdena i materialet om prestandautvärdering gäller under de utvärderingsvillkoren, och vi använder dem inte som säkerhetskriterium skilt från den faktiska tidsgränsen för påfyllning och buffertens marginal. Results for the Streaming Media Performance Assessment

Buffertstorlek och uppspelningsfördröjning

Om mer ljud buffras i förväg under samma villkor blir det lättare att absorbera tillfälliga påfyllningsfördröjningar, men nytt ljud som skapas får vänta bakom det ljud som redan har buffrats. En väntan som är acceptabel när man bara lyssnar på musik blir ändå en störande förskjutning mellan handling och ljud när man spelar på ett klaviatur eller bearbetar sin mikrofonröst och själv lyssnar på den. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Buffertmarginal och fördröjd respons
    accDescr: Om mer ljud buffras i förväg blir det lättare att absorbera tillfälliga påfyllningsfördröjningar, men väntetiden innan nytt ljud spelas upp ökar också.
    A["Buffra mer ljud i förväg"] --> B["Lättare att absorbera fördröjning"]
    B -->|"i gengäld"| C["Nytt ljud väntar bakom"]
    C --> D["Längre från handling till ljud"]

Figur 7: Att öka bufferten är en justering som ger marginal på bekostnad av svarstiden.

Det är varken så att ”mindre är bättre prestanda” eller att ”större är rätt”. Målet är att få tillräcklig marginal för att ljudet inte ska brytas, samtidigt som den svarstid som behövs behålls.

Att öka bufferten skapar marginal för tillfälliga leveransfördröjningar. Om den genomsnittliga leveransen i sig inte hinner med förbrukningen förlänger en större men ändlig buffert bara tiden tills den tar slut, och den löser inte heller att enheten kopplas från. Det är inte heller en rekommendation om att exklusivt läge löser allt. Exclusive-Mode Streams

480 ramar ljud vid 48 kHz

En PCM-ram är den enhet som samlar alla kanalers sampel som spelas upp vid samma tidpunkt. Att ljudet är i stereo betyder inte att tiden räknas genom att dubbla antalet ramar. Längden på det ljud som ett antal ramar motsvarar får man genom ”antal ramar ÷ samplingsfrekvens”; 480 ramar vid 48 kHz blir 480 ÷ 48000 sekunder, alltså 10 millisekunder. Ökar man antalet ramar och behåller 48 kHz blir också tiden för det ljud som kan buffras längre. Rendering a Stream

Den här tiden är inte detsamma som den totala latensen från att en tangent trycks ned tills ljudet hörs. Det beror på att även appen, drivrutinen, enheten och andra buffertar och bearbetningssteg tar tid. Läs även värdena i DAW-inställningar först efter att ha kontrollerat måttenheten och vilken buffert de gäller. Low Latency Audio

flowchart TB
    accTitle: Tid beräknad från antal ramar och total latens
    accDescr: 480 ramar delat med 48000, alltså 10 millisekunder, är den tid bufferten motsvarar; när bearbetning i app, drivrutin, enhet med mera läggs till blir det den totala latensen från tangent till ljud.
    A["480 ÷ 48000"] --> B["Buffertens 10 ms"]
    B -->|"annan bearbetning tillkommer"| C["Total latens från tangent till ljud"]

Figur 8: Tiden beräknad från antalet ramar är bara en del av den totala latensen.

Jämför reproduktionsvillkor

Först ringar vi in den kombination där problemet reproduceras, och går vidare till detaljerad inspelning bara när det behövs. Det som följer är en metod för att kontrollera orsaken, inte en lista över åtgärder där alla inställningsändringar ska göras på en gång.

Spara ditt arbete, avsluta skarpa möten och inspelningar och testa sedan på en volym som inte påfrestar öronen. Anteckna den ursprungliga utgången, ljudförbättringar, buffertvärden med mera så att du kan återställa dem. Hoppa över punkter där inställningen inte erbjuds, och ändra inte i registret eller liknande för att få fram inställningar.

1. Bestäm en och samma korta ljudkälla och observationstid, och kontrollera att problemet reproduceras under de ursprungliga villkoren.

   Anteckna Windows-version, appens namn och version, utdataenhet, anslutningssätt och drivrutinsversion. Notera också tidpunkt, åtgärd och antal gånger ljudet bröts. Om problemet inte reproduceras under de ursprungliga villkoren ska du inte dra slutsatsen att det har blivit bättre, utan gå tillbaka och ta reda på under vilka villkor det reproduceras.

2. Välj en jämförelse i tabellen nedan och spela upp med bara det villkoret ändrat.

   Villkor att jämföra	Vad som undersöks
   Lokalt sparad ljudkälla mot uppspelning via nätet	Uppstår det bara via nätet? Om innehållet är detsamma men formatet eller bearbetningsvägen skiljer sig, anteckna även det.
   Samma ljudkälla uppspelad i en annan app	Är det knutet till en viss app?
   Bluetooth eller annan utgång mot inbyggd eller trådbunden utgång	Är det knutet till en viss utdataväg?
   Ljudförbättringar på eller av	Ändras det i kombination med effektbearbetningen?
   Aktuell buffert i DAW eller liknande mot ett steg större värde	Ändras det när marginalen för förbuffring ökas? Är även fördröjningen från handling till ljud acceptabel?

3. Om du jämför ljudförbättringar stänger du tillfälligt av inställningen för den aktuella utgången.

   Välj den aktuella utgången under ”Inställningar” → ”System” → ”Ljud” i Windows och stäng av ”Ljudförbättringar” där det är tillgängligt. Om visningen eller vilka alternativ som finns skiljer sig åt, läs vägledningen för den versionen eller enheten. Fix distorted or crackling audio in Windows

4. Återställ den ändrade inställningen och testa igen med samma ljudkälla och observationstid.

   Ställ resultaten för ”ursprungliga villkor”, ”ett villkor ändrat” och ”återställda villkor” bredvid varandra. Återställ ändringar som inte hade någon effekt innan du går vidare till nästa jämförelse. Om du fortsätter att ändra kombinationer av inställningar vet du till slut inte vad som hjälpte.

5. Om du vill prova att byta drivrutin, kontrollera först den officiella distributionen och hur du återställer.

   Använd Windows Update eller enhetstillverkarens officiella distribution och anteckna versioner och inställningar före och efter ändringen. Kontrollera i förväg att det går att återställa, och rådgör med administratören om datorn är centralt hanterad. Betrakta inte problemet som löst bara för att uppspelningen fungerade en gång direkt efter uppdateringen, utan kontrollera under samma reproduktionsvillkor. Fix distorted or crackling audio in Windows

Det resultat du vill få fram är en anteckning som kopplar symtom till villkor, till exempel ”problemet reproduceras när den här appen används med den här utgången”. Även om du hittar en inställning som förbättrar läget ska den hållas isär från att orsaken är fastställd.

flowchart TB
    accTitle: Jämförelse där ett villkor ändras och återställs
    accDescr: Kontrollera reproduktion med samma ljudkälla, ändra ett villkor som app eller utgång och anteckna även resultatet efter återställningen.
    A["Spela upp med ursprunglig kombination"] --> B["Ändra ett villkor och spela upp"]
    B --> C["Återställ och spela upp"]
    C --> D["Anteckna villkor och tid för bortfall"]

Figur 9: Viktigare än att det blev bättre en gång är att bekräfta att villkor och symtom upprepade gånger hänger ihop.

Reproducerbarhet före och efter en ändring

”Symtomet gick att dämpa”, ”villkoren gick att ringa in” och ”grundorsaken kunde fastställas” är olika nivåer av resultat. Anteckna slutsatsen i linje med vad du faktiskt kunde observera.

flowchart TB
    accTitle: Tre resultat som pekar på ett samband med villkoret
    accDescr: Om problemet reproduceras under ursprungliga villkor, blir bättre när ett villkor ändras och reproduceras igen vid återställning är det en ledtråd till ett samband med villkoret, men det hålls isär från en fastställd orsak.
    A["Reproduceras under ursprungliga villkor"] --> B["Bättre när ett ändras"]
    B --> C["Reproduceras vid återställning"]
    C --> D["Ledtråd till samband med villkoret"]

Figur 10: Även när alla tre stämmer är det man vet bara en ledtråd till ett samband.

Låg CPU-användning bevisar inte att ljudets tidsgräns hölls. Samtidigt kan man inte heller säga, enbart utifrån att ljudet bröts, att fördröjd påfyllning var grundorsaken. Jämför ljudkälla, appens bearbetning, effekter, utdataväg med mera och gör bedömningen inom ramen för det du har observerat. Fix distorted or crackling audio in Windows

När du inför en tillfällig lösning, anteckna ursprunglig inställning, vad som ändrades, observationstid, om problemet återkom och vilken latens som är acceptabel. Om grundorsaken inte är fastställd, anteckna även det.

Spela in ljudbortfall med WPR

Det här gör du när jämförelser av villkor inte räcker för att ringa in orsaken, eller när du vill undersöka bearbetningen på drivrutinssidan. WPR är verktyget för inspelning och WPA verktyget för att analysera den sparade tidslinjen. Förbered Windows Performance Toolkit, de behörigheter som krävs för inspelning och en plats att spara ETL-filen på. Om verktyget ska installeras och användas för inspelning på en centralt hanterad dator, be administratören om det. Kontrollera visningsnamn och tillgängliga profiler i den version som installerats. Windows Performance Recorder

En ETL-fil kan innehålla processnamn, filsökvägar med mera. Kontrollera före inspelningen företagets regler och vem filen ska delas med, och bifoga den inte som den är på offentliga platser. Om en annan inspelningssession körs ska du inte stoppa den på eget bevåg, utan fråga den som är ansvarig. WPR How-to Topics

1. Öppna ”More Options” i WPR och välj en inspelningsprofil som passar syftet.

   Bland standardprofilerna finns ”Audio glitches” och ”CPU usage”. Välj en inställning där du kan undersöka diskontinuiteter i ljudet och processorns aktivitet. Kontrollera tillgängliga profiler, visningsnamn och vad som samlas in i den installerade versionen, och ställ inte in inspelning av alla typer under lång tid. Built-in Recording Profiles

2. Starta inspelningen innan du reproducerar ljudbortfallet.

   Om en fråga om att stoppa en befintlig inspelning visas, fortsätt inte utan avbryt starten och fråga den ansvarige. Håll villkoren lika som utan inspelning, och ha i åtanke att belastningen från själva inspelningen kan påverka symtomen. WPR How-to Topics

3. Spela upp under de villkor du hittade i jämförelsen och anteckna tidpunkt och åtgärd när ljudet bröts.

   Ta också med en kort problemfri period före och efter symtomet. Om problemet inte reproducerades, skriv det tydligt vid inspelningen och behandla den inte som en inspelning som har fångat orsaken.

4. När problemet har reproducerats avslutar du inspelningen med ”Save” och sparar ETL-filen.

   Med ”Cancel” sparas ingenting. Anteckna lagringsplats, reproduktionsvillkor, om det finns en inspelning och om det kom någon varning om förlorade händelser. Bedöm inte en osynlig period som normal i en inspelning med luckor. WPR How-to Topics

När du har ETL-filen och anteckningar om tidpunkt, åtgärd och villkor för ljudbortfallet är du redo att jämföra i WPA. Att inspelningen har sparats betyder inte nödvändigtvis att de händelser som behövs har samlats in. Innehållet kontrolleras i nästa avsnitt, ”Körning och väntan kring ljudbortfallet”.

flowchart TB
    accTitle: Gör en kort inspelning som innehåller ljudbortfallet
    accDescr: Starta inspelningen i WPR, reproducera symtomet och anteckna tidpunkten, stoppa och undersök den sparade inspelningen i WPA.
    A["Starta inspelning i WPR"] --> B["Reproducera bortfallet under samma villkor"]
    B --> C["Anteckna tid och åtgärd, spara"]
    C --> D["Zooma in intervallet i WPA"]

Figur 11: CPU-användning som man tittar på efter att symtomet är över räcker inte; det behövs en inspelning av intervallet där symtomet uppstod.

Körning och väntan kring ljudbortfallet

Ha den sparade ETL-filen och anteckningarna om tidpunkten för reproduktionen till hands. Det som följer är en utgångspunkt för undersökningen i WPA. Om en detaljerad analys med anropsstackar och symboler behövs, be administratören eller en utvecklare om hjälp och hantera inspelningen varsamt.

1. Öppna ETL-filen i WPA och zooma in på tiden före och efter ljudbortfallet utifrån de insamlade ljudhändelserna och tidpunkten för reproduktionen.

   Behåll också ett intervall utan symtom för jämförelse. Titta inte bara på rangordningen av maxvärden, utan jämför inom samma tidsintervall.

2. Kontrollera ”DPC/ISR” och ”CPU Usage (Precise)” inom samma intervall.

   Om data som behövs saknas, kontrollera att profilen kan samla in dem och gå tillbaka till inspelningen i WPR. Att något inte finns i inspelningen är inte detsamma som att det inte fanns något problem. CPU Analysis, Built-in Recording Profiles

3. Skilj på om de trådar som har med ljudet att göra var körbara men väntade i kö, eller om de väntade på data eller liknande.

   I det första fallet kontrollerar du om DPC/ISR eller liknande körde länge på den berörda logiska processorn. I det andra fallet följer du med hjälp av insamlade händelser och anropsstackar vad som löste upp väntan. Eftersom en tråd som körs också kan pausas av ett avbrott, begränsa dig inte till Ready-tiden utan lägg även DPC/ISR-intervallen ovanpå. CPU Analysis

4. Anteckna tillsammans tidskopplingen till ljudbortfallet, de berörda processorerna och resultaten av att ändra villkor.

   Fastställ inte en viss enhet eller drivrutin som orsak enbart utifrån modulnamnet för en lång DPC/ISR. Det kan också vara så att du tittar på ett stort värde från en annan tidpunkt, eller på en gemensam del som flera enheter passerar.

flowchart TB
    accTitle: Undersök hur tråden väntade i intervallet med ljudbortfall
    accDescr: Zooma in intervallet före och efter ljudbortfallet och titta på ljudtrådens tillstånd. Väntar den körbar i kö, jämför med DPC:er och ISR:er på samma processor; väntar den på data eller liknande, följ den bearbetning som löste upp väntan.
    A["Zooma in tiden kring bortfallet"] --> B{"Trådens tillstånd"}
    B -->|"väntar i kö"| C["DPC/ISR"]
    B -->|"väntar på data"| D["Det som löste väntan"]

Figur 12: Plocka inte bara ut maxvärden, utan läs dem tillsammans med intervallet där ljudbearbetningen behövdes.

Går det inte att fastställa orsaken lämnar du över undersökningen som ej avslutad. Bifoga versioner av OS, app, enhet och drivrutin, reproduktionssteg, resultat före och efter ändringar, tidpunkt för förekomsten, insamlingsprofil och om det kom någon varning om förlorade händelser. Dela ETL-filen enligt företagets regler och bara med den som ansvarar för undersökningen.

Förinläsning i ljudappar

Om du själv utvecklar en ljudapp, utforma den så att bearbetningen som fyller nästa buffert hinner klart till varje tidsgräns. WASAPI har ett sätt att via en händelse få veta när bufferten kan bearbetas. Exclusive-Mode Streams

MMCSS är en mekanism som fördelar processorresurser till trådar för tidskritisk multimediabearbetning. Den har ingen funktion för att förbereda data från disk i förväg eller för att ta bort väntan på lås. Även när du använder MMCSS för fördelningen behövs det separat en design som förbereder data och minskar väntan. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Vad MMCSS ansvarar för
    accDescr: MMCSS fördelar processorresurser till trådar för tidskritisk bearbetning, men förberedelse av data och minskning av väntan på lås sköts med en separat design.
    M["MMCSS: fördelar CPU-resurser"] -.->|"behövs separat"| D["Förbered data och minska väntan"]

Figur 13: Att fördela processorresurser och att utforma så att data hinner fram är två olika uppgifter.

Designprincipen är att separera bearbetningen som läser från filer eller nätverk från bearbetningen som lämnar över ljud. Förberedelser vars tidsåtgång är svår att förutse görs i förväg, och för överlämningen används en buffert som allokerats i förväg. På ljudsidan utformas det så att man inte behöver vänta på svar från användargränssnittet, långa lås eller synkron loggskrivning.

flowchart TB
    accTitle: Separera svårförutsägbar förberedelse från ljudleveransen
    accDescr: En design där inläsning och liknande görs i förväg och de förberedda data lämnas till ljudbearbetningen via en buffert, så att långa väntetider strax före tidsgränsen minskar.
    A["Förbered data i förväg"] --> B["Förallokerat överlämningsområde"]
    B --> C["Ljudbearbetningen lämnar det som behövs"]
    C --> D["Leverans till ljudutgången"]

Figur 14: Tidskrävande arbete flyttas bort från ögonblicket strax före överlämningen av ljud.

Om förberedelsesidan stannar länge tar lagret slut även med den här separeringen. Registrera inte bara den genomsnittliga bearbetningstiden, utan även de tillfällen då lång bearbetning eller väntan förekom och hur många gånger leveransen misslyckades, på ett sätt som inte stör ljudbearbetningen. Kontrollera den buffertstorlek och period som faktiskt valdes via API:et eller drivrutinen, och anta inte att det angivna värdet användes oförändrat. Rendering a Stream, Low Latency Audio

Både sifferexemplen och designexemplen är till för förklaringen och är varken rekommenderade inställningsvärden för en viss enhet eller en garanti för att ljudet aldrig bryts i någon miljö.

Effekten av realtidsprioritet

Vi rekommenderar inte generellt att användare ändrar hela spelarens prioritet till ”Realtid”. Det finns en risk att andra viktiga processer hindras, och att höja en vanlig tråds prioritet löser inte DPC/ISR eller väntan på data och lås. I utveckling används mekanismer som MMCSS och en design som inte för in långa väntetider i ljudleveransen. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Väntan som finns kvar även med realtidsprioritet
    accDescr: Även om spelaren får realtidsprioritet kan vanliga trådar inte gå före DPC:er och ISR:er på samma processor, väntan på data och lås finns kvar och det finns en risk att andra viktiga processer hindras.
    A["Spelaren till realtidsprioritet"] --> B["Kan inte gå före DPC/ISR"]
    B --> C["Väntan på data och lås kvarstår"]
    C --> D["Risk att hindra annat"]

Figur 15: Även med högre prioritet finns den väntan kvar som fördröjer påfyllningen av ljud.

Relaterade artiklar

• ”Processorschemaläggning” och inställningen för bakgrundstjänster i Windows
• Felsök 100 % diskanvändning i Windows på ett säkert sätt
• Varför är RDP trögt trots en snabb anslutning?

Referenser

• Microsoft Learn, Rendering a Stream. Leverans till uppspelningsbufferten, kvarvarande mängd, faktisk buffertstorlek och definitionen av PCM-ram.
• Microsoft Learn, Exclusive-Mode Streams. Tidpunkten för buffertleverans och ljudstörningar, avvägningen mot latens samt händelsestyrd leverans. Det är ingen generell rekommendation av exklusivt läge i sig.
• Microsoft Learn, Low Latency Audio. Ljudvägen i Windows, buffertar, enheter, effektbearbetning och latens samt avvägningar för låg latens.
• Microsoft Learn, CPU Analysis. Logiska processorer, trådtillstånden Ready/Waiting, sambandet mellan DPC/ISR och trådkörning samt CPU-analys i WPA.
• Microsoft Learn, Introduction to DPCs. Mekanismen som håller avbrottshanteringen kort och skjuter resten av arbetet till en DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Långa och frekventa DPC/ISR, otillräcklig dataleverans och ljudstörningar. Utvärderingens varningsvärden generaliseras inte till säkerhetskriterier för alla enheter.
• Microsoft Support, Fix distorted or crackling audio in Windows. Kontroll av ljudförbättringar, format, drivrutiner med mera.
• Microsoft Learn, Windows Performance Recorder. ETW-inspelning och analys med WPA, användning av Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options i WPR och standardprofiler som Audio glitches och CPU usage.
• Microsoft Learn, WPR How-to Topics. Att starta en inspelning och spara med Save, konflikter med befintliga sessioner samt försiktighet kring personuppgifter och förlorade händelser.
• Microsoft Learn, Multimedia Class Scheduler Service. Fördelning av processorresurser till tidskritisk multimediabearbetning.
• Microsoft Learn, Scheduling Priorities. Process- och trådprioriteter samt varningar om realtidsprioritet.

Relaterade artiklar

De senaste artiklarna med samma taggar. Fördjupa dig i närliggande ämnen.

Relaterade ämnen

Ämnessidor som ligger nära det här temat. Utgå från artikeln och gå vidare till relaterade tjänster och andra artiklar.

Tjänster som hänger ihop med det här ämnet

Den här artikeln hör ihop med följande tjänstesidor. Välj den ingång som ligger närmast.

Vanliga frågor

Vanliga frågor om artikelns ämne som brukar komma upp när man rådfrågar oss.

Varför hackar ljudet när CPU-användningen bara ligger runt 10 %?

Ljud har en tidsgräns: nästa data måste fyllas på innan den data som spelas upp tar slut. Även om den totala CPU-användningen är låg kan påfyllningen missa tidsgränsen om ljudbearbetningen inte kunde köras just då eller väntade på data som behövdes. Alla ljudbortfall har inte nödvändigtvis den här orsaken, och det krävs också jämförelser där utdataenheten eller appen byts.

Försvinner ljudbortfallen om jag gör ljudbufferten större?

Om påfyllningen tillfälligt blir försenad kan en stor buffert ibland absorbera det. Men väntetiden innan det buffrade ljudet spelas upp ökar också. Det är ingen inställning som löser en ihållande brist på bearbetningskapacitet eller en enhet som kopplas från. I appar och drivrutiner där värdet kan ändras antecknar du det ursprungliga värdet och jämför ett steg i taget.

Hur många millisekunder ljud är 480 ramar vid 48 kHz?

Det är 480 ÷ 48000 sekunder, alltså 10 millisekunder. En PCM-ram är den enhet som samlar alla kanalers sampel vid samma tidpunkt. Värdet är längden på det ljud som det antalet ramar motsvarar, inte den totala latensen inklusive enhet och app.

Är en drivrutin med lång körtid för DPC eller ISR boven bakom ljudbortfallet?

Den är en kandidat, men en rangordning efter körtid räcker inte för att fastställa det. Jämför intervallet där ljudet bröts med ljudtrådens väntan och DPC/ISR-körningen på samma processor. Dra inte slutsatsen att en viss enhet eller drivrutin är felaktig bara utifrån modulnamnet, och kontrollera även resultaten när reproduktionsvillkoren har ändrats.

Blir det bättre om spelaren får realtidsprioritet?

Vi rekommenderar det inte generellt. Att höja prioriteten för en vanlig tråd gör inte att den kan gå före vanliga DPC:er och ISR:er på samma processor, och väntan på data eller lås försvinner inte heller. Utvecklare använder mekanismer som MMCSS och en design som inte för in väntan i ljudleveransen, och användare jämför först reproduktionsvillkoren och utdatavägen.

Författarprofil

Profilsidan för artikelns författare.

Go Komura

Företrädare för KomuraSoft LLC

Arbetar med Windows-programvaruutveckling, teknisk rådgivning och felsökning, med särskild styrka i projekt med befintliga tillgångar och i utredning av fel vars orsak är svår att se.