Hvorfor faller lyden ut når CPU-bruken er lav? – sett ut fra buffere og frister

Mens du hører på musikk, faller lyden av og til ut med et kort «klikk». Oppgavebehandling viser en CPU-bruk på rundt 10 %, men likevel er det bare lyden som ikke er stabil. Hvorfor faller lyden ut i en slik situasjon, selv om CPU-en har kapasitet til overs?

Selv om CPU-bruken er lav, kan lyden falle ut hvis de neste lyddataene ikke fylles på innen fristen. Det er fordi de neste dataene må leveres mens lyden som er igjen i bufferen, spilles av. At påfyllingen forsinkes av venting på data eller låser, av DPC/ISR på den logiske CPU-en som trengs, og lignende, skjer også uten at CPU-en som helhet er fullt utnyttet. Exclusive-Mode Streams, CPU Analysis

Et hørbart «klikk» er likevel ikke nok til å fastslå at det dreier seg om en underrun. Lignende symptomer oppstår også på grunn av lydkilden, appen, lydeffekter, utdataenheten og annet. Sammenlign først med samme lydkilde ved å endre én betingelse om gangen og sette den tilbake igjen, og hvis du fortsatt ikke kan snevre inn årsaken, tar du opp forløpet før og etter lydutfallet. Fix distorted or crackling audio in Windows

Artikkelen tar for seg dette spørsmålet og spørsmålene som følger: «Bør bufferen bare gjøres større?» og «Hva må man sammenligne og ta opp for å snevre inn årsaken?». Den fastslår ikke årsaken til en konkret feil ut fra CPU-bruken eller den hørte lyden alene.

Artikkelen handler først og fremst om lydutgang i Windows 11. Sammenligningene omfatter innebygd, kablet, USB- og Bluetooth-utgang og lignende, og for musikkproduksjonsprogramvare (DAW) behandles også sammenligninger der appen eller driveren tilbyr en bufferinnstilling. Design av hele opptakskjeden og diagnose av trådløs kommunikasjon for de enkelte enhetene er ikke dekket uttømmende.

Forklaringen bruker delt modus (shared mode) som grunneksempel. Den faktiske veien, bufferstørrelsen og behandlingsperioden varierer med app, API, driver og enhet, og det finnes heller ikke noe skjermbilde for bufferinnstillinger som er felles for alle apper. Low Latency Audio

CPU-bruken, de 10 millisekundene som er igjen, påfyllingstidspunktene og de andre tallene i artikkelen er antakelser for forklaringens skyld. De er ikke en rapport om målt reproduksjon eller forbedring på en bestemt PC. Handlingene i andre halvdel er kontrolltrinn som du utfører i ditt eget miljø.

Mekanismen kan leses i rekkefølge fra neste avsnitt, «Lydavspillingsbufferen». Handlingene for å undersøke lydutfall står i «Sammenlign betingelser for reproduksjon» og «Ta opp lydutfall med WPR».

I diagrammet markerer en heldekkende linje en relasjon som alltid gjelder, og en stiplet linje en betinget relasjon (vilkårene står for hver relasjon på detaljsiden). Den fullstendige listen over relasjoner (5 i alt, med belegg og sikkerhet) og definisjonene av de viktigste begrepene finner du på detaljsiden for kunnskapskartet (på japansk). Data: JSON-LD / Turtle

Lydavspillingsbufferen

En musikkfil som bare ligger lagret, får ikke høyttalerne til å spille. En app gjør lyddata klare og leverer dem til utdataenheten via Windows og driveren. Lydavspillingsbufferen er et område som midlertidig holder dataene som skal spilles av om litt. Mens enheten spiller av de aktuelle dataene, gjør forsyningssiden de neste dataene klare og fyller dem på. Rendering a Stream

flowchart TB
    accTitle: Lyden lagres litt i forveien før den spilles av
    accDescr: Forløpet der forberedte lyddata fylles i bufferen, og de neste dataene gjøres klare mens enheten spiller av.
    A["Gjør neste lyd klar"] --> B["Fyll i bufferen"]
    B --> C["Spill av lagret lyd"]
    C -.->|"Før den er brukt opp"| A

Figur 1: For at avspillingen skal kunne fortsette, må påfyllingen holde tritt med siden som bruker lyden.

Figur 1 er en prinsippskisse som bare viser forholdet mellom påfylling og forbruk. Den behandler ikke de mange bufferne i den faktiske lydveien som ett fysisk område. Low Latency Audio

Bufferens oppgave er å ta opp korte tidsforskyvninger mellom siden som gjør lyden klar, og siden som bruker den, slik at avspillingen blir sammenhengende. Bufferens kapasitet er likevel ikke det samme som mengden data som ennå ikke er spilt av, og som ligger der akkurat nå. At det finnes «en kapasitet på 10 millisekunder», betyr ikke at det alltid er 10 millisekunder igjen. Rendering a Stream

Her kaller vi den tidsmessige begrensningen, at de nødvendige neste dataene må leveres før dataene som spilles av, er brukt opp, for fristen for påfylling. Lydbehandling er en oppgave der det kreves at dataene «var klare til tidspunktet da lyden skulle spilles». Det er ikke nok at de «ble beregnet til slutt». Når forsyningen ikke rekker fram i tide og det ikke er flere data å spille av, kalles tilstanden en underrun, og den fører til lydutfall og klikk. Selv om dataene kommer for sent, kan et utfall som allerede er hørt, ikke fylles igjen i etterkant. Exclusive-Mode Streams

Lyddataenes vei

I vanlig delt modus tar lydmotoren i Windows imot dataene som avspillingsappen har gjort klare, blander flere lyder og legger på effekter, og sender dem deretter videre til driveren og utdataenheten. Avspillingsappen står både for å lese inn lydkilden og for å forsyne utgangen, mens driveren og utdataenheten bringer dataene over til enhetssiden og spiller dem av. Low Latency Audio

flowchart TB
    accTitle: Lyddataenes vei i delt modus
    accDescr: Lydmotoren blander og legger effekter på dataene som avspillingsappen har gjort klare, og sender dem til driveren, før utdataenheten spiller dem av.
    A["Avspillingsapp: gjør data klare"] --> E["Lydmotor: miksing og effekter"]
    E --> D["Driver: bringer til enheten"]
    D --> O["Utdataenhet: spiller av"]

Figur 2: Et eksempel med delt modus. Behandlingen og bufferne underveis avhenger av API og enhet.

Enheten kan også ha egen behandling og egne buffere, så den samlede forsinkelsen bestemmes ikke bare av bufferen på appsiden. Forklaringen forutsetter veien i delt modus og betyr ikke at alle API-er går gjennom den samme behandlingen. Low Latency Audio

Påfylling med 10 ms igjen

Anta at det akkurat nå er 10 millisekunder med data som ennå ikke er spilt av, igjen i bufferen. Kommer neste påfylling etter 8 millisekunder, fortsetter lyden mens det fortsatt er noe igjen, men kan det ikke fylles på før etter 12 millisekunder, går dataene i dette forenklede eksempelet tomme etter 10 millisekunder.

flowchart TB
    accTitle: Med de samme 10 ms igjen avgjør tidspunktet for påfylling resultatet
    accDescr: Som en antakelse for forklaringens skyld vises det at påfylling etter 8 millisekunder rekker fram i tide for 10 millisekunder med gjenværende avspillingsdata, mens påfylling etter 12 millisekunder kommer etter at dataene er brukt opp.
    A["10 ms igjen"] --> B{"Neste påfylling"}
    B -->|"Etter 8 ms"| C["Lyden fortsetter"]
    B -->|"Etter 12 ms"| D["Går tom ved 10 ms"]

Figur 3: Et eksempel med forenklet tid. Det avgjørende er ikke bare om det ble fylt på, men når.

CPU-bruk og forsinket påfylling

CPU-bruken viser hvor travelt det var innenfor et bestemt tidsrom. Det er noe annet enn om lydbehandlingen kunne kjøre i det øyeblikket den måtte. Selv om CPU-en har kapasitet til overs det meste av et sekund, kan lyden falle ut på grunn av den ene forsinkelsen hvis det bare én gang oppstår et tidsrom på 12 millisekunder uten påfylling. Regnekraften som er til overs etterpå, kan ikke ta igjen et avspillingstidspunkt som allerede er passert. CPU Analysis

flowchart TB
    accTitle: Gjennomsnittlig ledig kapasitet og én enkelt forsinket påfylling
    accDescr: Selv om CPU-en har kapasitet til overs det meste av et sekund, kan lyden falle ut på grunn av den ene forsinkelsen hvis det bare én gang oppstår et tidsrom på 12 millisekunder uten påfylling.
    A["CPU ledig det meste av sekundet"] --> B["Én gang 12 ms uten påfylling"]
    B --> C["Lyden faller ut den ene gangen"]

Figur 4: Selv med ledig kapasitet i snitt kan et passert avspillingstidspunkt ikke tas igjen.

Det er ikke bare beregningstiden som spiser av fristen. Ventetiden før behandlingen starter, og ventetiden til de nødvendige dataene kommer fram, teller også med. Derfor endrer vi også spørsmålet i feilsøkingen fra bare «Hvor mange prosent brukte CPU-en?» til «Hva ventet den neste lyden på i det øyeblikket lyden falt ut?».

Venting på data og låser

Anta at behandlingen som gjør lyddata klare, venter på at en fil skal bli ferdig innlest. Det samme gjelder hvis den venter på en lås som en annen del av appen holder. Den ventende behandlingen bruker ikke selv særlig mye CPU, men på enhetssiden fortsetter avspillingen, og lyden som er igjen, blir mindre. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Avspillingen fortsetter også i ventetid uten CPU-bruk
    accDescr: Mens lydbehandlingen venter på data eller en lås, bruker den ikke CPU, men avspillingen fortsetter og resten blir mindre, slik at bufferen kan gå tom hvis påfyllingen forsinkes.
    A["Lydbehandling venter på data"] --> B["Den bruker ikke CPU"]
    B --> C["Avspillingen fortsetter imens"]
    C --> D["Sen påfylling tømmer lageret"]

Figur 5: At det ikke brukes CPU, er ikke det samme som at det nødvendige arbeidet er gjort.

DPC, ISR og lydtråder

En ISR er behandlingen som reagerer på et interrupt fra en enhet. En DPC er en mekanisme som utsetter det gjenværende arbeidet til senere for å holde interruptbehandlingen kort. Vanlige DPC-er kjøres før vanlige tråder på samme logiske CPU, og mens en vanlig DPC eller ISR kjører, kan ingen vanlige tråder kjøres på den logiske CPU-en. Introduction to DPCs, CPU Analysis

Selv om CPU-en som helhet har kapasitet til overs, kan forsyningen bli forsinket hvis disse varer lenge eller forekommer ofte på CPU-en som lydbehandlingen trenger. Microsofts materiale om ytelsesanalyse av lyd og video nevner også lange DPC/ISR-er fra drivere for nettverk, lagring, grafikk og lignende som mulige årsaker til lydutfall. Det er ikke alltid nok å undersøke bare enheten som spiller av lyden. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Når svar til enheter forsinker kjøringen av lyd
    accDescr: Hvis vanlige DPC-er eller ISR-er varer lenge på CPU-en som lydbehandlingen trenger, forsinkes kjøringen av tråden, noe som kan påvirke fristen for påfylling.
    A["DPC og ISR på samme CPU"] -->|"Hvis de varer lenge"| B["Lydkjøringen må vente"]
    B --> C["Neste påfylling forsinkes"]
    C --> D["Utfall når resten går tom"]

Figur 6: Behandling utenfor enheten som spiller av lyden, kan også indirekte påvirke påfyllingen av lyd.

Det kan ikke trekkes en felles grense av typen «Hvis DPC-er holder seg under så og så mange mikrosekunder, faller lyden aldri ut på noen PC». Advarselsverdiene i materialet om ytelsesvurdering gjelder under de betingelsene vurderingen ble gjort under, og de brukes ikke som sikkerhetskriterium løsrevet fra den faktiske påfyllingsfristen og bufferens margin. Results for the Streaming Media Performance Assessment

Bufferstørrelse og avspillingsforsinkelse

Lagrer man under samme betingelser mer lyd i forveien, blir det lettere å ta opp midlertidige forsinkelser i påfyllingen, men nyprodusert lyd må til gjengjeld vente bak lyden som allerede er lagret. En ventetid som er akseptabel når man bare hører på musikk, gjør forskyvningen mellom handling og lyd plagsom når man spiller på et keyboard eller bearbeider sin egen stemme fra mikrofonen og lytter selv. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Bufferens margin og forsinket respons
    accDescr: Lagrer man mer lyd i forveien, blir det lettere å ta opp midlertidige forsinkelser i påfyllingen, men ventetiden før ny lyd spilles av, blir også lengre.
    A["Lagre mer lyd i forveien"] --> B["Lettere å ta opp forsinkelser"]
    B -->|"Til gjengjeld"| C["Ny lyd venter bakerst"]
    C --> D["Lyden kommer senere enn handlingen"]

Figur 7: Å øke bufferen er en justering som skaper margin på bekostning av rask respons.

Det er verken slik at «jo mindre, jo bedre ytelse», eller at «jo større, jo riktigere». Målet er å beholde den responstiden som trengs, og samtidig skape nok margin til at lyden ikke faller ut.

Å øke bufferen skaper margin mot midlertidige forsinkelser i forsyningen. Hvis selve den gjennomsnittlige forsyningen ikke klarer å holde følge med forbruket, forlenger en større, men fortsatt begrenset buffer bare tiden til den går tom, og den løser heller ikke at en enhet mister forbindelsen. Det er heller ikke en anbefaling om at eksklusiv modus løser alt. Exclusive-Mode Streams

Lyd på 480 frames ved 48 kHz

En PCM-frame er en enhet som samler samplene fra alle kanaler som spilles av på samme tidspunkt. Selv i stereo dobler man ikke antallet frames for å beregne tiden. Lengden på lyden som et antall frames representerer, finner man som «antall frames ÷ samplingsfrekvens», så 480 frames ved 48 kHz gir 480 ÷ 48000 sekunder, altså 10 millisekunder. Øker man antallet frames ved uendret 48 kHz, blir lydtiden som kan lagres, også lengre. Rendering a Stream

Denne tiden er ikke det samme som den samlede forsinkelsen fra du trykker på en tangent, til du hører lyden. Det er fordi app, driver, enhet og andre buffere og annen behandling også tar tid. Kontroller også måleenheten og hvilken buffer verdien gjelder for, når du leser innstillingsverdiene i en DAW. Low Latency Audio

flowchart TB
    accTitle: Tid beregnet ut fra antall frames og samlet forsinkelse
    accDescr: De 10 millisekundene man får ved å dele 480 frames på 48000, er tiden bufferen representerer, og legger man til behandlingen i app, driver, enhet og annet, får man den samlede forsinkelsen fra tangent til lyd.
    A["480 ÷ 48000"] --> B["De 10 ms bufferen utgjør"]
    B -->|"Annen behandling legges til"| C["Samlet forsinkelse fra tangent til lyd"]

Figur 8: Tiden beregnet ut fra antall frames er en del av den samlede forsinkelsen.

Sammenlign betingelser for reproduksjon

Snevre først inn kombinasjonen der feilen kan gjenskapes, og gå bare videre til detaljert opptak hvis det trengs. Det følgende er en framgangsmåte for å avklare årsaken, ikke en liste over tiltak der alle innstillingsendringer gjøres på én gang.

Lagre arbeidet ditt, avslutt møter og opptak som foregår på ordentlig, og test med et lydvolum som ikke belaster ørene. Noter den opprinnelige utdataenheten, lydforbedringer, bufferverdier og lignende, slik at du kan gå tilbake til dem. Hopp over punkter der innstillingen ikke finnes, og ikke endre registeret eller lignende for å få fram en innstilling.

1. Velg den samme korte lydkilden og observasjonstiden, og kontroller om feilen oppstår under de opprinnelige betingelsene.

   Noter Windows-versjonen, appens navn og versjon, utdataenheten, tilkoblingstypen og driverversjonen. Noter også tidspunkt, handling og antall for lydutfallene. Oppstår ikke feilen under de opprinnelige betingelsene, skal du ikke konkludere med at det har blitt bedre, men gå tilbake til å finne betingelsene der den oppstår.

2. Velg én sammenligning fra tabellen nedenfor, og spill av med bare den betingelsen endret.

   Betingelse som sammenlignes	Det som undersøkes
   Lokalt lagret lydkilde og avspilling via nettet	Oppstår det bare via nettet? Noter det også hvis formatet eller behandlingsveien er en annen, selv om innholdet er det samme.
   Samme lydkilde spilt av i en annen app	Henger det sammen med en bestemt app?
   Bluetooth- eller annen utgang og innebygd eller kablet utgang	Henger det sammen med en bestemt utgangsvei?
   Lydforbedringer slått på og av	Endrer det seg i kombinasjon med effektbehandlingen?
   Nåværende buffer i en DAW eller lignende og ett trinn større	Endrer det seg når mer margin lagres i forveien? Er forsinkelsen fra handling til lyd også akseptabel?

3. Når du sammenligner lydforbedringer, slår du innstillingen midlertidig av for den aktuelle utgangen.

   Velg den aktuelle utgangen under «Innstillinger» → «System» → «Lyd» i Windows, og slå av «Lydforbedringer» hvis det finnes i ditt miljø. Hvis visningen ser annerledes ut eller punktet mangler, så sjekk veiledningen for din versjon og enhet. Fix distorted or crackling audio in Windows

4. Sett den endrede innstillingen tilbake, og prøv igjen med samme lydkilde og observasjonstid.

   Still resultatene for «opprinnelige betingelser», «én betingelse endret» og «satt tilbake» opp ved siden av hverandre. En endring uten effekt settes tilbake til den opprinnelige tilstanden før du går videre til en annen sammenligning. Fortsetter du å endre kombinasjonen av innstillinger, kan du ikke lenger se hva som virket.

5. Hvis du vil prøve å bytte driver, gjør du det først etter at du har kontrollert den offisielle distribusjonen og en måte å gjenopprette på.

   Bruk Windows Update eller enhetsprodusentens offisielle distribusjon, og noter versjon og innstillinger før og etter endringen. Kontroller på forhånd at du kan gå tilbake, og snakk med administratoren hvis PC-en administreres sentralt. Ikke betrakt problemet som løst bare fordi avspillingen fungerte én gang rett etter oppdateringen, men kontroller under de samme reproduksjonsbetingelsene. Fix distorted or crackling audio in Windows

Resultatet du er ute etter, er en oversikt som kobler symptom og betingelser, for eksempel «Feilen oppstår i denne appen når denne utgangen brukes». Også når du finner en innstilling som gjør det bedre, holder du det atskilt fra å fastslå årsaken.

flowchart TB
    accTitle: Sammenligning med én endret betingelse som settes tilbake
    accDescr: Feilen kontrolleres med samme lydkilde, én betingelse som app eller utgang endres, og resultatet etter tilbakestillingen noteres også.
    A["Spill av med opprinnelig kombinasjon"] --> B["Spill av med én betingelse endret"]
    B --> C["Sett tilbake og spill av"]
    C --> D["Noter betingelse og tid for utfall"]

Figur 9: Kontroller at betingelse og symptom henger sammen gang på gang, framfor at det ble bedre én gang.

Reproduserbarhet før og etter endringen

«Symptomet ble dempet», «betingelsene ble snevret inn» og «den grunnleggende årsaken ble funnet» er ulike stadier. Noter konklusjonen slik at den samsvarer med det du faktisk har kunnet observere.

flowchart TB
    accTitle: Tre resultater som peker på en sammenheng med betingelsen
    accDescr: Oppstår feilen under de opprinnelige betingelsene, blir den bedre når én betingelse endres, og oppstår den igjen ved tilbakestilling, er det et spor som peker på en sammenheng med betingelsen, men det holdes atskilt fra å fastslå årsaken.
    A["Oppstår under opprinnelige betingelser"] --> B["Bedre med én endring"]
    B --> C["Oppstår igjen ved tilbakestilling"]
    C --> D["Spor til sammenheng med betingelsen"]

Figur 10: Selv når alle tre er oppfylt, kommer du bare fram til et spor om en sammenheng.

Lav CPU-bruk er ikke bevis for at lydens frist ble overholdt. Samtidig kan man heller ikke ut fra selve lydutfallet si at forsinket påfylling var den grunnleggende årsaken. Sammenlign lydkilde, appens behandling, effekter, utgangsvei og lignende, og vurder innenfor det du har observert. Fix distorted or crackling audio in Windows

Når du tar i bruk en midlertidig løsning, noterer du den opprinnelige innstillingen, endringen, observasjonstiden, om feilen har kommet tilbake, og hvilken forsinkelse som kan aksepteres. Er den grunnleggende årsaken ennå ikke fastslått, noterer du også det.

Ta opp lydutfall med WPR

Dette gjør du når en sammenligning av betingelser ikke er nok til å snevre inn årsaken, eller når du vil undersøke behandlingen på driversiden. WPR er verktøyet for opptak, og WPA er verktøyet for analyse av den lagrede tidslinjen. Klargjør Windows Performance Toolkit, rettighetene opptaket krever, og en plassering for ETL-filen. Skal verktøyene installeres og brukes til opptak på en administrert PC, ber du administratoren om det. Kontroller visningsnavn og tilgjengelige profiler i versjonen du har installert. Windows Performance Recorder

En ETL-fil kan inneholde prosessnavn, filbaner og lignende. Kontroller virksomhetens regler og hvem filen kan deles med, før du tar opp, og ikke legg den ved uendret på et offentlig sted. Kjører det en annen opptaksøkt, skal du ikke stoppe den på eget initiativ, men spørre den ansvarlige. WPR How-to Topics

1. Åpne «More Options» i WPR, og velg en opptaksprofil som passer til formålet.

   Blant standardprofilene finnes «Audio glitches» og «CPU usage». Velg et oppsett som gjør det mulig å undersøke brudd i lyden og CPU-ens aktivitet. Kontroller tilgjengelige profiler, visningsnavn og innsamlet innhold i den installerte versjonen, og ikke velg et oppsett som tar opp alle typer over lang tid. Built-in Recording Profiles

2. Start opptaket før du gjenskaper lydutfallet.

   Hvis du blir spurt om et eksisterende opptak skal stoppes, skal du ikke fortsette, men avbryte starten og spørre den ansvarlige. Hold betingelsene like med situasjonen uten opptak, og noter også at belastningen fra selve opptaket kan endre symptomet. WPR How-to Topics

3. Spill av under betingelsene du fant i sammenligningen, og noter tidspunkt og handling for utfallet.

   Ta også med litt problemfri tid før og etter symptomet. Hvis feilen ikke oppsto under et opptak, skriver du det tydelig, og du behandler ikke opptaket som et som har fanget årsaken.

4. Når feilen er gjenskapt, avslutter du opptaket med «Save» og lagrer ETL-filen.

   Med «Cancel» lagres ingenting. Noter plasseringen, reproduksjonsbetingelsene, om symptomet kom med i opptaket, og om det var advarsler om tapte hendelser. I et opptak med tap skal du ikke vurdere tidsrommene som ikke er synlige, som normale. WPR How-to Topics

Når du har ETL-filen og notater om tidspunkt, handling og betingelser for lydutfallet, er du klar til å sammenholde dem i WPA. At opptaket er lagret, betyr ikke nødvendigvis at de nødvendige hendelsene ble samlet inn. Innholdet kontrolleres i neste avsnitt, «Kjøring og venting rundt utfallet».

flowchart TB
    accTitle: Ta et kort opptak som inneholder lydutfallet
    accDescr: Start opptaket i WPR, gjenskap symptomet og noter tidspunktet, stopp og lagre, og undersøk deretter opptaket i WPA.
    A["Start opptak i WPR"] --> B["Gjenskap utfall under samme betingelser"]
    B --> C["Noter tid og handling, og lagre"]
    C --> D["Zoom inn rundt utfallet i WPA"]

Figur 11: CPU-bruken når symptomet er over, er ikke nok; du trenger et opptak av tidsrommet der symptomet oppsto.

Kjøring og venting rundt utfallet

Ha den lagrede ETL-filen og notatene om tidspunktene for feilen klare. Det følgende er et utgangspunkt for undersøkelsen i WPA. Blir det behov for en detaljert analyse med stakker og symboler, ber du en administrator eller utvikler om det og er oppmerksom på hvordan opptaket håndteres.

1. Åpne ETL-filen i WPA, og zoom inn på tiden før og etter lydutfallet ut fra lydhendelsene som er samlet inn, og tidspunktene for feilen.

   Behold også et tidsrom uten symptomer til sammenligning. Ikke se bare på rangeringen av maksimumsverdier, men sammenlign innenfor det samme tidsintervallet.

2. Kontroller «DPC/ISR» og «CPU Usage (Precise)» i det samme intervallet.

   Mangler de nødvendige dataene, kontrollerer du om profilen kan samle dem inn, og går tilbake til opptaket i WPR. At det ikke finnes noe opptak, er ikke det samme som at det ikke var noe problem. CPU Analysis, Built-in Recording Profiles

3. Skill mellom om trådene som har med lyden å gjøre, var klare til å kjøre, men sto i kø, eller om de ventet på data eller lignende.

   I det første tilfellet sammenholder du med om DPC/ISR eller lignende har kjørt lenge på de aktuelle logiske CPU-ene. I det andre tilfellet følger du med de innsamlede hendelsene og stakkene hva som avsluttet ventingen. Siden en tråd som kjører, også kan bli avbrutt av et interrupt, skal du ikke se bare på Ready-tiden, men også legge DPC/ISR-tidsrommene oppå. CPU Analysis

4. Noter samlet hvordan tidspunktene stemmer med lydutfallet, hvilke CPU-er som er involvert, og resultatene av å endre betingelsene.

   Ikke fastslå en bestemt enhet eller driver som årsak ut fra modulnavnet på en lang DPC/ISR alene. Du kan også være i ferd med å se på en høy verdi fra et annet tidspunkt eller på en felles del som flere enheter går gjennom.

flowchart TB
    accTitle: Undersøk hvordan det ventes i tidsrommet med lydutfall
    accDescr: Zoom inn på tiden før og etter lydutfallet, og se på lydtrådens tilstand. Står den klar i kø, sammenholdes den med DPC eller ISR på samme CPU, og venter den på data eller lignende, følges behandlingen som avsluttet ventingen.
    A["Zoom inn rundt utfallet"] --> B{"Trådens tilstand"}
    B -->|"Står i kø"| C["DPC og ISR"]
    B -->|"Venter på data"| D["Det som avsluttet ventingen"]

Figur 12: Ikke plukk ut bare maksimumsverdiene, men les dem sammen med tidsrommet der lydbehandlingen trengte å kjøre.

Hvis årsaken ikke kan finnes, overleverer du undersøkelsen som uavklart. Legg ved versjonene av OS, app, enhet og driver, trinnene for å gjenskape feilen, resultatene før og etter endringer, tidspunktene for utfallene, innsamlingsprofilen og om det var advarsler om tap. Del ETL-filen bare med dem som har ansvaret for undersøkelsen, i tråd med virksomhetens regler.

Forhåndslasting i lydapper

Når du selv utvikler en lydapp, må behandlingen som fyller neste buffer, utformes slik at den rekker fristen hver gang. WASAPI har en metode der appen via en hendelse får beskjed når bufferen kan behandles. Exclusive-Mode Streams

MMCSS er en mekanisme som fordeler CPU-ressurser til tråder i tidskritisk multimediebehandling. Den har ingen funksjon for å hente data fra disken i forveien eller fjerne venting på låser. Også når du bruker fordelingen fra MMCSS, trengs det i tillegg et design som forbereder data og reduserer ventingen. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Området MMCSS dekker
    accDescr: MMCSS fordeler CPU-ressurser til tråder i tidskritisk behandling, men forberedelse av data og mindre venting på låser løses med et eget design.
    M["MMCSS: fordeler CPU-ressurser"] -.->|"Trengs i tillegg"| D["Klargjør data, reduser venting"]

Figur 13: Fordeling av CPU-ressurser og et design som får data fram i tide, er to forskjellige oppgaver.

Designprinsippet er å skille behandlingen som leser fra filer eller nettverk, fra behandlingen som leverer lyden. Forberedelse der varigheten er vanskelig å forutsi, gjøres i forveien, og til overleveringen brukes en forhåndsallokert buffer. På lydsiden innretter du det slik at det ikke må ventes på svar fra brukergrensesnittet, lange låser eller synkron skriving av logger.

flowchart TB
    accTitle: Skill uforutsigbar forberedelse fra lydforsyningen
    accDescr: Et design der innlesing og lignende skjer i forveien, og de forberedte dataene leveres til lydbehandlingen via en buffer, slik at lange ventetider rett før fristen reduseres.
    A["Klargjør data i forveien"] --> B["Forhåndsallokert overleveringsområde"]
    B --> C["Lydbehandling leverer det som trengs"]
    C --> D["Forsyner lydens utgang"]

Figur 14: Flytt tidkrevende arbeid bort fra øyeblikket rett før lyden overleveres.

Hvis forberedelsessiden står stille lenge, går lageret tomt til tross for denne atskillelsen. Registrer ikke bare den gjennomsnittlige behandlingstiden, men også gangene da det oppsto lang behandling eller venting, og antallet ganger forsyningen ikke lyktes, på en måte som ikke forstyrrer lydbehandlingen. Kontroller den faktisk valgte bufferstørrelsen og perioden via API-et eller driveren, og ikke anta at den angitte verdien ble brukt uendret. Rendering a Stream, Low Latency Audio

Både talleksemplene og designeksemplene er ment som forklaring og er verken anbefalte innstillinger for bestemte enheter eller en garanti for at lyden ikke faller ut i et vilkårlig miljø.

Virkningen av prioriteten Sanntid

Det anbefales ikke generelt at brukere setter hele spilleren til prioriteten «Sanntid». Det innebærer en risiko for å hindre annen viktig behandling, og høyere prioritet for vanlige tråder fjerner ikke DPC/ISR eller venting på data og låser. I utvikling bruker man mekanismer som MMCSS og et design som ikke trekker lange ventetider inn i lydforsyningen. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Venting som består, selv med prioriteten Sanntid
    accDescr: Selv om spilleren får prioriteten Sanntid, kan vanlige tråder ikke komme foran DPC eller ISR på samme CPU, venting på data og låser består, og det er også en risiko for å hindre annen viktig behandling.
    A["Spiller satt til Sanntid"] --> B["Kommer ikke foran DPC og ISR"]
    B --> C["Venting på data og låser består"]
    C --> D["Risiko for å hindre annen behandling"]

Figur 15: Selv med høyere prioritet består ventingen som forsinker påfyllingen av lyd.

Relaterte artikler

• «Prosessorplanlegging» og innstillingen for bakgrunnstjenester i Windows
• Trygg feilsøking av 100 % diskbruk i Windows
• Hvorfor er RDP treg når forbindelsen er rask?

Referanser

• Microsoft Learn, Rendering a Stream. Forsyning av avspillingsbufferen, gjenværende mengde, den faktiske bufferstørrelsen og definisjonen av en PCM-frame.
• Microsoft Learn, Exclusive-Mode Streams. Tidspunkt for bufferforsyning og glitches i lyden, avveining mot forsinkelse og hendelsesdrevet forsyning. Henvisningen er ikke en generell anbefaling av eksklusiv modus som sådan.
• Microsoft Learn, Low Latency Audio. Lydveien i Windows, buffere, enheter, effektbehandling og forsinkelse samt avveiningene ved lav latens.
• Microsoft Learn, CPU Analysis. Logiske CPU-er, trådtilstandene Ready/Waiting, forholdet mellom DPC/ISR og trådkjøring samt CPU-analyse i WPA.
• Microsoft Learn, Introduction to DPCs. Mekanismen som holder interruptbehandlingen kort og utsetter det gjenværende arbeidet til en DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Lange og hyppige DPC/ISR-er, utilstrekkelig dataforsyning og glitches i lyden. Vurderingens advarselsverdier generaliseres ikke til et sikkerhetskriterium for alle enheter.
• Microsoft Support, Fix distorted or crackling audio in Windows. Kontroll av lydforbedringer, format, drivere og annet.
• Microsoft Learn, Windows Performance Recorder. ETW-opptak, analyse med WPA og bruk av Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options i WPR og standardprofiler som Audio glitches og CPU usage.
• Microsoft Learn, WPR How-to Topics. Start av opptak og lagring med Save, konflikter med eksisterende økter samt forsiktighet med personopplysninger og tapte hendelser.
• Microsoft Learn, Multimedia Class Scheduler Service. Fordeling av CPU-ressurser til tidskritisk multimediebehandling.
• Microsoft Learn, Scheduling Priorities. Prosess- og trådprioriteter samt forbehold om prioriteten Sanntid.

Relaterte artikler

Nyere artikler med de samme taggene. Fordyp deg i beslektede emner.

Relaterte temaer

Dette er temasider som ligger nær temaet for artikkelen. Med artikkelen som utgangspunkt kan du gå videre til relaterte tjenester og andre artikler.

Tjenester knyttet til dette temaet

Denne artikkelen henger sammen med følgende tjenestesider. Se dem gjennom den inngangen som ligger nærmest.

Ofte stilte spørsmål

Vanlige spørsmål ved rådgivning om temaet for denne artikkelen.

Hvorfor faller lyden ut når CPU-bruken bare er rundt 10 %?

Lyd har en frist: De neste dataene må fylles på før dataene som spilles av nå, er brukt opp. Selv om den samlede CPU-bruken er lav, kan fristen bli overskredet hvis lydbehandlingen ikke får kjøre akkurat i det øyeblikket, eller hvis den venter på data den trenger. Ikke alle lydutfall har denne årsaken, og det er også nødvendig å sammenligne med en annen utdataenhet eller app.

Forsvinner lydutfallene hvis jeg gjør lydbufferen større?

Hvis påfyllingen bare blir midlertidig forsinket, kan en større buffer noen ganger ta opp forsinkelsen. Til gjengjeld blir ventetiden før den lagrede lyden spilles av, også lengre. Innstillingen løser verken vedvarende mangel på regnekraft eller en enhet som mister forbindelsen. I apper og drivere der verdien kan endres, noterer du den opprinnelige verdien og sammenligner ett trinn om gangen.

Hvor mange millisekunder lyd er 480 frames ved 48 kHz?

Det er 480 ÷ 48000 sekunder, altså 10 millisekunder. En PCM-frame er en enhet som samler samplene fra alle kanaler på samme tidspunkt. Verdien er lengden på lyden som dette antallet frames representerer, og ikke den samlede forsinkelsen inkludert enheter og apper.

Er en driver med lange DPC- eller ISR-kjøretider synderen bak lydutfallene?

Den er en kandidat, men en rangering etter kjøretid er ikke nok til å fastslå det. Sammenhold tidsrommet der lydutfallet oppsto, med lydtrådens venting og med DPC/ISR-kjøring på samme CPU. Ikke konkluder ut fra modulnavnet alene med at en bestemt enhet eller driver har en feil, og kontroller også resultatene av å endre reproduksjonsbetingelsene.

Blir det bedre hvis spilleren settes til prioriteten Sanntid?

Det anbefales ikke generelt. Selv om en vanlig tråd får høyere prioritet, kan den ikke komme foran vanlige DPC-er eller ISR-er på samme CPU, og venting på data eller låser forsvinner heller ikke. Utviklere bruker mekanismer som MMCSS og et design som ikke trekker inn venting, og brukere sammenligner først reproduksjonsbetingelsene og utgangsveien.

Om forfatteren

Profilside for artikkelens forfatter.

Go Komura

Representant for KomuraSoft LLC

Arbeider særlig med Windows-programvareutvikling, teknisk rådgivning og feilsøking, og har sin styrke i prosjekter med eksisterende systemer og i undersøkelse av feil der årsaken er vanskelig å se.