Hvorfor falder lyden ud, når CPU-forbruget er lavt? – set ud fra buffere og frister

Mens du lytter til musik, falder lyden en gang imellem ud med et kort »klik«. Jobliste viser et CPU-forbrug på omkring 10 %, men alligevel er det kun lyden, der ikke er stabil. Hvorfor falder lyden ud i sådan en situation, selv om CPU’en har kapacitet til overs?

Selv om CPU-forbruget er lavt, kan lyden falde ud, hvis de næste lyddata ikke fyldes på inden fristen. Det skyldes, at de næste data skal leveres, mens den lyd, der er tilbage i bufferen, bliver afspillet. At genopfyldningen forsinkes af ventetid på data eller låse, af DPC/ISR på den logiske CPU, der er brug for, og lignende, sker også, uden at CPU’en som helhed er fuldt udnyttet. Exclusive-Mode Streams, CPU Analysis

Et hørbart »klik« er dog ikke nok til at fastslå, at der er tale om en underrun. Lignende symptomer opstår også på grund af lydkilden, appen, lydeffekter, outputenheden og andet. Sammenlign først med den samme lydkilde ved at ændre én betingelse ad gangen og sætte den tilbage igen, og kan du stadig ikke indsnævre årsagen, så optag forløbet før og efter lydudfaldet. Fix distorted or crackling audio in Windows

Artiklen behandler det spørgsmål og de spørgsmål, der følger efter: »Skal bufferen bare gøres større?« og »Hvad skal man sammenligne og optage for at indsnævre årsagen?«. Den fastslår ikke årsagen til en konkret fejl ud fra CPU-forbruget eller den hørte lyd alene.

Artiklen handler primært om lydoutput i Windows 11. Sammenligningerne omfatter indbygget, kablet, USB- og Bluetooth-output og lignende, og for musikproduktionssoftware (DAW) behandles også sammenligninger, hvor appen eller driveren tilbyder en bufferindstilling. Design af hele optagekæden og diagnose af trådløs kommunikation for de enkelte enheder er ikke dækket udtømmende.

Forklaringen bruger delt tilstand (shared mode) som grundeksempel. Den faktiske vej, bufferstørrelse og behandlingsperiode varierer med app, API, driver og enhed, og der findes heller ingen skærm til bufferindstillinger, som er fælles for alle apps. Low Latency Audio

CPU-forbruget, de 10 millisekunders restmængde, genopfyldningstidspunkterne og de øvrige tal i artiklen er antagelser til forklaringen. De er ikke en rapport om målt reproduktion eller forbedring på en bestemt pc. Handlingerne i anden halvdel er kontroltrin, som du udfører i dit eget miljø.

Mekanismen kan læses i rækkefølge fra det næste afsnit, »Lydafspilningsbufferen«. Handlingerne til at undersøge lydudfald står i »Sammenlign betingelser for reproduktion« og »Optag lydudfald med WPR«.

I diagrammet markerer en fuldt optrukket linje en relation, der altid gælder, og en stiplet linje en betinget relation (betingelserne står for hver relation på detaljesiden). Den fulde liste over relationer (5 i alt, med belæg og sikkerhed) og definitionerne af de vigtigste begreber er samlet på detaljesiden for vidensoversigten (på japansk). Data: JSON-LD / Turtle

Lydafspilningsbufferen

En musikfil, der bare ligger gemt, får ikke højttalerne til at spille. En app gør lyddata klar og leverer dem til outputenheden via Windows og driveren. Lydafspilningsbufferen er et område, der midlertidigt rummer de data, der skal afspilles om lidt. Mens enheden afspiller de aktuelle data, gør forsyningssiden de næste data klar og fylder dem på. Rendering a Stream

flowchart TB
    accTitle: Lyden lagres lidt i forvejen, før den afspilles
    accDescr: Forløbet, hvor forberedte lyddata fyldes i bufferen, og de næste data gøres klar, mens enheden afspiller.
    A["Gør næste lyd klar"] --> B["Fyld i bufferen"]
    B --> C["Afspil lagret lyd"]
    C -.->|"Før den er brugt op"| A

Figur 1: For at afspilningen kan fortsætte, skal genopfyldningen holde trit med den side, der bruger lyden.

Figur 1 er en begrebsskitse, der kun viser forholdet mellem genopfyldning og forbrug. Den behandler ikke de mange buffere i den faktiske lydvej som ét fysisk område. Low Latency Audio

Bufferens opgave er at opsuge korte tidsforskydninger mellem den side, der gør lyden klar, og den side, der bruger den, så afspilningen bliver sammenhængende. Bufferens kapacitet er dog ikke det samme som mængden af ikke-afspillede data, der ligger i den lige nu. At der er »en kapacitet på 10 millisekunder«, betyder ikke, at der altid er 10 millisekunder tilbage. Rendering a Stream

Her kalder vi den tidsmæssige begrænsning, at de nødvendige næste data skal leveres, før de data, der afspilles, er brugt op, for fristen for genopfyldning. Lydbehandling er en opgave, hvor det kræves, at data »var klar til det tidspunkt, hvor lyden skulle spille«. Det er ikke nok, at de »blev beregnet til sidst«. Når forsyningen ikke når frem i tide, og der ikke er flere data at afspille, kaldes tilstanden en underrun, og den fører til lydudfald og klik. Selv hvis dataene kommer for sent, kan et udfald, der allerede er hørt, ikke udfyldes bagefter. Exclusive-Mode Streams

Lyddataenes vej

I almindelig delt tilstand modtager lydmotoren i Windows de data, som afspilningsappen har gjort klar, blander flere lyde og lægger effekter på og sender dem derefter videre til driveren og outputenheden. Afspilningsappen står både for at indlæse lydkilden og for at forsyne outputtet, mens driveren og outputenheden bringer dataene over på enhedssiden og afspiller dem. Low Latency Audio

flowchart TB
    accTitle: Lyddataenes vej i delt tilstand
    accDescr: Lydmotoren blander og lægger effekter på de data, afspilningsappen har gjort klar, og sender dem til driveren, hvorefter outputenheden afspiller dem.
    A["Afspilningsapp: gør data klar"] --> E["Lydmotor: mix og effekter"]
    E --> D["Driver: bringer til enheden"]
    D --> O["Outputenhed: afspiller"]

Figur 2: Et eksempel med delt tilstand. Behandlingen og bufferne undervejs afhænger af API og enhed.

Enheden kan også have sin egen behandling og sine egne buffere, så den samlede forsinkelse bestemmes ikke alene af bufferen på appsiden. Forklaringen forudsætter vejen i delt tilstand og betyder ikke, at alle API’er går gennem den samme behandling. Low Latency Audio

Genopfyldning med 10 ms tilbage

Antag, at der lige nu er 10 millisekunders ikke-afspillede data tilbage i bufferen. Kommer den næste genopfyldning efter 8 millisekunder, fortsætter lyden, mens der stadig er noget tilbage, men kan der ikke fyldes på før efter 12 millisekunder, slipper dataene i dette forenklede eksempel op efter 10 millisekunder.

flowchart TB
    accTitle: Med de samme 10 ms tilbage afgør tidspunktet for genopfyldning resultatet
    accDescr: Som en antagelse til forklaringen vises det, at genopfyldning efter 8 millisekunder når frem i tide for 10 millisekunders resterende afspilningsdata, mens genopfyldning efter 12 millisekunder kommer, efter at dataene er brugt op.
    A["10 ms tilbage"] --> B{"Næste genopfyldning"}
    B -->|"Efter 8 ms"| C["Lyden fortsætter"]
    B -->|"Efter 12 ms"| D["Slipper op ved 10 ms"]

Figur 3: Et eksempel med forenklet tid. Det afgørende er ikke kun, om der blev fyldt på, men hvornår.

CPU-forbrug og forsinket genopfyldning

CPU-forbruget viser, hvor travlt der var inden for et bestemt tidsrum. Det er noget andet end, om lydbehandlingen kunne køre i det øjeblik, den skulle. Selv hvis CPU’en har kapacitet til overs det meste af et sekund, kan lyden falde ud på grund af den ene forsinkelse, hvis der blot én gang er et tidsrum på 12 millisekunder uden genopfyldning. Den regnekraft, der er til overs bagefter, kan ikke indhente et afspilningstidspunkt, der allerede er passeret. CPU Analysis

flowchart TB
    accTitle: Gennemsnitlig ledig kapacitet og en enkelt forsinket genopfyldning
    accDescr: Selv hvis CPU'en har kapacitet til overs det meste af et sekund, kan lyden falde ud på grund af den ene forsinkelse, hvis der blot én gang er et tidsrum på 12 millisekunder uden genopfyldning.
    A["CPU ledig det meste af sekundet"] --> B["Én gang 12 ms uden påfyldning"]
    B --> C["Lyden falder ud den ene gang"]

Figur 4: Selv med ledig kapacitet i gennemsnit kan et passeret afspilningstidspunkt ikke indhentes.

Det er ikke kun beregningstiden, der æder af fristen. Ventetiden, før behandlingen går i gang, og ventetiden, indtil de nødvendige data når frem, tæller også med. Derfor ændrer vi også spørgsmålet i undersøgelsen fra kun »Hvor mange procent brugte CPU’en?« til »Hvad ventede den næste lyd på i det øjeblik, lyden faldt ud?«.

Ventetid på data og låse

Antag, at den behandling, der gør lyddata klar, venter på, at en fil bliver færdigindlæst. Det samme gælder, hvis den venter på en lås, som en anden del af appen holder. Den ventende behandling bruger ikke selv ret meget CPU, men på enhedssiden fortsætter afspilningen, og den resterende lyd bliver mindre. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Afspilningen fortsætter også i ventetid uden CPU-forbrug
    accDescr: Mens lydbehandlingen venter på data eller en lås, bruger den ikke CPU, men afspilningen fortsætter, og resten bliver mindre, så bufferen kan løbe tom, hvis genopfyldningen forsinkes.
    A["Lydbehandling venter på data"] --> B["Den bruger ikke CPU"]
    B --> C["Afspilningen fortsætter imens"]
    C --> D["Sen påfyldning tømmer lageret"]

Figur 5: At der ikke bruges CPU, er ikke det samme som, at det nødvendige arbejde er gjort.

DPC, ISR og lydtråde

En ISR er den behandling, der reagerer på et interrupt fra en enhed. En DPC er en mekanisme, der udskyder det resterende arbejde til senere for at holde interruptbehandlingen kort. Almindelige DPC’er køres før almindelige tråde på samme logiske CPU, og mens en almindelig DPC eller ISR kører, kan der ikke køres almindelige tråde på den logiske CPU. Introduction to DPCs, CPU Analysis

Selv om CPU’en som helhed har kapacitet til overs, kan forsyningen blive forsinket, hvis disse varer længe eller forekommer ofte på den CPU, lydbehandlingen har brug for. Microsofts materiale om ydeevneanalyse af lyd og video nævner også lange DPC/ISR’er fra drivere til netværk, lagring, grafik og lignende som mulige årsager til lydudfald. Det er ikke altid nok kun at undersøge den enhed, der afspiller lyden. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Når svar på enheder forsinker lydens kørsel
    accDescr: Hvis almindelige DPC'er eller ISR'er varer længe på den CPU, lydbehandlingen har brug for, forsinkes trådens kørsel, hvilket kan påvirke fristen for genopfyldning.
    A["DPC og ISR på samme CPU"] -->|"Hvis de varer længe"| B["Lydkørslen må vente"]
    B --> C["Næste påfyldning forsinkes"]
    C --> D["Udfald, når resten slipper op"]

Figur 6: Behandling uden for den enhed, der afspiller lyden, kan også indirekte påvirke genopfyldningen af lyd.

Der kan ikke trækkes en fælles grænse af typen »Hvis DPC’er holder sig under så og så mange mikrosekunder, falder lyden aldrig ud på nogen pc«. Advarselsværdierne i materialet om ydeevnevurdering gælder under de betingelser, vurderingen blev foretaget under, og de bruges ikke som sikkerhedskriterium løsrevet fra den faktiske genopfyldningsfrist og bufferens margin. Results for the Streaming Media Performance Assessment

Bufferstørrelse og afspilningsforsinkelse

Lagrer man under samme betingelser mere lyd i forvejen, bliver det lettere at opsuge midlertidige forsinkelser i genopfyldningen, men nyskabt lyd må til gengæld vente bag den lyd, der allerede er lagret. En ventetid, der er acceptabel, når man bare lytter til musik, gør forskydningen mellem handling og lyd generende, når man spiller på et keyboard eller bearbejder sin stemme fra mikrofonen og selv lytter med. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Bufferens margin og forsinket respons
    accDescr: Lagrer man mere lyd i forvejen, bliver det lettere at opsuge midlertidige forsinkelser i genopfyldningen, men ventetiden, før ny lyd afspilles, bliver også længere.
    A["Lagr mere lyd i forvejen"] --> B["Lettere at opsuge forsinkelser"]
    B -->|"Til gengæld"| C["Ny lyd venter bagest"]
    C --> D["Lyden kommer senere end handlingen"]

Figur 7: At øge bufferen er en justering, der skaber margin på bekostning af hurtig respons.

Det er hverken sådan, at »jo mindre, jo bedre ydeevne«, eller at »jo større, jo mere rigtigt«. Målet er at bevare den responstid, der er brug for, og samtidig skabe nok margin til, at lyden ikke falder ud.

At øge bufferen skaber margin over for midlertidige forsinkelser i forsyningen. Hvis selve den gennemsnitlige forsyning ikke kan følge med forbruget, forlænger en større, men stadig begrænset buffer kun tiden, indtil den løber tom, og den løser heller ikke, at en enhed mister forbindelsen. Det er heller ikke en anbefaling om, at eksklusiv tilstand løser alt. Exclusive-Mode Streams

Lyd på 480 frames ved 48 kHz

En PCM-frame er en enhed, der samler samplene fra alle kanaler, som afspilles på samme tidspunkt. Selv i stereo fordobler man ikke antallet af frames for at beregne tiden. Længden af den lyd, et antal frames repræsenterer, findes som »antal frames ÷ samplingsfrekvens«, så 480 frames ved 48 kHz giver 480 ÷ 48000 sekunder, altså 10 millisekunder. Øger man antallet af frames ved uændret 48 kHz, bliver den lydtid, der kan lagres, også længere. Rendering a Stream

Denne tid er ikke det samme som den samlede forsinkelse, fra du trykker på en tangent, til du hører lyden. Det skyldes, at app, driver, enhed samt andre buffere og anden behandling også tager tid. Kontrollér også måleenheden og den buffer, værdien gælder for, når du læser indstillingsværdierne i en DAW. Low Latency Audio

flowchart TB
    accTitle: Tid beregnet ud fra antal frames og samlet forsinkelse
    accDescr: De 10 millisekunder, man får ved at dividere 480 frames med 48000, er den tid, bufferen repræsenterer, og lægges behandlingen i app, driver, enhed og andet til, får man den samlede forsinkelse fra tangent til lyd.
    A["480 ÷ 48000"] --> B["De 10 ms, bufferen udgør"]
    B -->|"Anden behandling lægges til"| C["Samlet forsinkelse fra tangent til lyd"]

Figur 8: Tiden beregnet ud fra antal frames er en del af den samlede forsinkelse.

Sammenlign betingelser for reproduktion

Indsnævr først den kombination, hvor fejlen kan genskabes, og gå kun videre til detaljeret optagelse, hvis det er nødvendigt. Det følgende er en fremgangsmåde til at afklare årsagen, ikke en liste over tiltag, hvor alle indstillingsændringer udføres på én gang.

Gem dit arbejde, afslut møder og optagelser, der foregår for alvor, og test ved en lydstyrke, der ikke belaster ørerne. Notér den oprindelige outputenhed, lydforbedringer, bufferværdier og lignende, så du kan vende tilbage til dem. Spring punkter over, hvor indstillingen ikke findes, og ændr ikke registreringsdatabasen eller lignende for at få en indstilling frem.

1. Vælg den samme korte lydkilde og observationstid, og kontrollér, om fejlen opstår under de oprindelige betingelser.

   Notér Windows-versionen, appens navn og version, outputenheden, forbindelsestypen og driverversionen. Notér også tidspunkt, handling og antal for lydudfaldene. Opstår fejlen ikke under de oprindelige betingelser, skal du ikke konkludere, at det er blevet bedre, men vende tilbage til at finde de betingelser, hvor den opstår.

2. Vælg én sammenligning fra tabellen nedenfor, og afspil med kun den betingelse ændret.

   Betingelse, der sammenlignes	Det, der undersøges
   Lokalt gemt lydkilde og afspilning via nettet	Opstår det kun via nettet? Notér det også, hvis formatet eller behandlingsvejen er en anden, selv om indholdet er det samme.
   Samme lydkilde afspillet i en anden app	Hænger det sammen med en bestemt app?
   Bluetooth- eller anden output og indbygget eller kablet output	Hænger det sammen med en bestemt outputvej?
   Lydforbedringer slået til og fra	Ændrer det sig i kombination med effektbehandlingen?
   Nuværende buffer i en DAW eller lignende og ét trin større	Ændrer det sig, når der lagres mere margin i forvejen? Er forsinkelsen fra handling til lyd også acceptabel?

3. Når du sammenligner lydforbedringer, slår du indstillingen midlertidigt fra for det pågældende output.

   Vælg det pågældende output under »Indstillinger« → »System« → »Lyd« i Windows, og slå »Lydforbedringer« fra, hvis det findes i dit miljø. Hvis visningen ser anderledes ud, eller punktet mangler, så se vejledningen for din version og enhed. Fix distorted or crackling audio in Windows

4. Sæt den ændrede indstilling tilbage, og prøv igen med samme lydkilde og observationstid.

   Stil resultaterne for »oprindelige betingelser«, »én betingelse ændret« og »sat tilbage« op ved siden af hinanden. En ændring uden effekt sættes tilbage til den oprindelige tilstand, før du går videre til en anden sammenligning. Bliver du ved med at ændre kombinationen af indstillinger, kan du ikke længere se, hvad der virkede.

5. Hvis du vil prøve at skifte driver, så gør det først, når du har kontrolleret den officielle distribution og en måde at gendanne på.

   Brug Windows Update eller enhedsproducentens officielle distribution, og notér version og indstillinger før og efter ændringen. Kontrollér på forhånd, at du kan vende tilbage, og tal med administratoren, hvis pc’en administreres centralt. Betragt ikke problemet som løst, bare fordi afspilningen lykkedes én gang lige efter opdateringen, men kontrollér under de samme reproduktionsbetingelser. Fix distorted or crackling audio in Windows

Det resultat, du vil have, er en optegnelse, der kobler symptom og betingelser, for eksempel »Fejlen opstår i denne app, når dette output bruges«. Også når du finder en indstilling, der forbedrer situationen, holder du det adskilt fra at fastslå årsagen.

flowchart TB
    accTitle: Sammenligning med én ændret betingelse, der sættes tilbage
    accDescr: Fejlen kontrolleres med samme lydkilde, én betingelse som app eller output ændres, og resultatet efter tilbagestillingen noteres også.
    A["Afspil med oprindelig kombination"] --> B["Afspil med én betingelse ændret"]
    B --> C["Sæt tilbage og afspil"]
    C --> D["Notér betingelse og tid for udfald"]

Figur 9: Kontrollér, at betingelse og symptom gentagne gange hænger sammen, frem for at det blev bedre én gang.

Reproducerbarhed før og efter ændringen

»Symptomet blev dæmpet«, »betingelserne blev indsnævret« og »den grundlæggende årsag blev fundet« er forskellige stadier. Notér konklusionen, så den svarer til det, du faktisk har kunnet observere.

flowchart TB
    accTitle: Tre resultater, der peger på en sammenhæng med betingelsen
    accDescr: Opstår fejlen under de oprindelige betingelser, forbedres den, når én betingelse ændres, og opstår den igen ved tilbagestilling, er det et spor, der peger på en sammenhæng med betingelsen, men det holdes adskilt fra at fastslå årsagen.
    A["Opstår under oprindelige betingelser"] --> B["Bedre med én ændring"]
    B --> C["Opstår igen ved tilbagestilling"]
    C --> D["Spor til sammenhæng med betingelsen"]

Figur 10: Selv når alle tre er opfyldt, når du kun frem til et spor om en sammenhæng.

Et lavt CPU-forbrug er ikke bevis for, at lydens frist blev overholdt. Samtidig kan man heller ikke ud fra selve lydudfaldet sige, at forsinket genopfyldning var den grundlæggende årsag. Sammenlign lydkilde, appens behandling, effekter, outputvej og lignende, og vurder inden for det, du har observeret. Fix distorted or crackling audio in Windows

Når du tager en midlertidig løsning i brug, så notér den oprindelige indstilling, ændringen, observationstiden, om fejlen er vendt tilbage, og den forsinkelse, der kan accepteres. Er den grundlæggende årsag endnu ikke fastslået, noterer du også det.

Optag lydudfald med WPR

Dette gør du, når en sammenligning af betingelser ikke er nok til at indsnævre årsagen, eller når du vil undersøge behandlingen på driversiden. WPR er værktøjet til optagelse, og WPA er værktøjet til analyse af den gemte tidslinje. Klargør Windows Performance Toolkit, de rettigheder, optagelsen kræver, og en placering til ETL-filen. Skal værktøjerne installeres og bruges til optagelse på en administreret pc, så bed administratoren om det. Kontrollér visningsnavne og tilgængelige profiler i den version, du har installeret. Windows Performance Recorder

En ETL-fil kan indeholde procesnavne, filstier og lignende. Kontrollér virksomhedens regler, og hvem filen må deles med, før du optager, og vedhæft den ikke uændret et offentligt sted. Kører der en anden optagesession, skal du ikke stoppe den på egen hånd, men spørge den ansvarlige. WPR How-to Topics

1. Åbn »More Options« i WPR, og vælg en optageprofil, der passer til formålet.

   Blandt standardprofilerne findes »Audio glitches« og »CPU usage«. Vælg en opsætning, der gør det muligt at undersøge afbrydelser i lyden og CPU’ens aktivitet. Kontrollér tilgængelige profiler, visningsnavne og indsamlet indhold i den installerede version, og lad være med at vælge en opsætning, der optager alle typer i lang tid. Built-in Recording Profiles

2. Start optagelsen, før du genskaber lydudfaldet.

   Hvis du bliver spurgt, om en eksisterende optagelse skal stoppes, så fortsæt ikke, men annuller starten og spørg den ansvarlige. Hold betingelserne ens med situationen uden optagelse, og notér også, at belastningen fra selve optagelsen kan ændre symptomet. WPR How-to Topics

3. Afspil under de betingelser, du fandt ved sammenligningen, og notér tidspunkt og handling for udfaldet.

   Medtag også lidt problemfri tid før og efter symptomet. Hvis fejlen ikke opstod under en optagelse, så skriv det tydeligt, og behandl ikke optagelsen som en, der har fanget årsagen.

4. Når fejlen er genskabt, afslutter du optagelsen med »Save« og gemmer ETL-filen.

   Med »Cancel« gemmes intet. Notér placeringen, reproduktionsbetingelserne, om symptomet kom med i optagelsen, og om der var advarsler om tabte hændelser. I en optagelse med tab må du ikke vurdere de tidsrum, der ikke kan ses, som normale. WPR How-to Topics

Når du har ETL-filen og noter om tidspunkt, handling og betingelser for lydudfaldet, er du klar til at sammenholde dem i WPA. At optagelsen er gemt, betyder ikke nødvendigvis, at de nødvendige hændelser blev indsamlet. Indholdet kontrolleres i næste afsnit, »Kørsel og ventetid omkring udfaldet«.

flowchart TB
    accTitle: Tag en kort optagelse, der indeholder lydudfaldet
    accDescr: Start optagelsen i WPR, genskab symptomet og notér tidspunktet, stop og gem, og undersøg derefter optagelsen i WPA.
    A["Start optagelse i WPR"] --> B["Genskab udfald på samme betingelser"]
    B --> C["Notér tid og handling, og gem"]
    C --> D["Zoom ind omkring udfaldet i WPA"]

Figur 11: CPU-forbruget, når symptomet er ovre, er ikke nok; du har brug for en optagelse af det tidsrum, hvor symptomet opstod.

Kørsel og ventetid omkring udfaldet

Hav den gemte ETL-fil og noterne om tidspunkterne for fejlen klar. Det følgende er et udgangspunkt for undersøgelsen i WPA. Bliver der brug for en detaljeret analyse med stakke og symboler, så bed en administrator eller udvikler om det, og vær opmærksom på, hvordan optagelsen håndteres.

1. Åbn ETL-filen i WPA, og zoom ind på tiden før og efter lydudfaldet ud fra de lydhændelser, der er indsamlet, og tidspunkterne for fejlen.

   Behold også et tidsrum uden symptomer til sammenligning. Se ikke kun på rangeringen af maksimumværdier, men sammenlign inden for det samme tidsinterval.

2. Kontrollér »DPC/ISR« og »CPU Usage (Precise)« i det samme interval.

   Mangler de nødvendige data, så kontrollér, om profilen kan indsamle dem, og gå tilbage til optagelsen i WPR. At der ikke er nogen optagelse, er ikke det samme som, at der ikke var noget problem. CPU Analysis, Built-in Recording Profiles

3. Skeln mellem, om de tråde, der har med lyden at gøre, var klar til at køre, men stod i kø, eller om de ventede på data eller lignende.

   I det første tilfælde sammenholder du med, om DPC/ISR eller lignende har kørt længe på de relevante logiske CPU’er. I det andet tilfælde følger du med de indsamlede hændelser og stakke, hvad der afsluttede ventetiden. Da en kørende tråd også kan blive afbrudt af et interrupt, skal du ikke kun se på Ready-tiden, men også lægge DPC/ISR-tidsrummene oven på. CPU Analysis

4. Notér samlet, hvordan tidspunkterne passer med lydudfaldet, hvilke CPU’er der er involveret, og resultaterne af at ændre betingelserne.

   Fastslå ikke en bestemt enhed eller driver som årsag ud fra modulnavnet på en lang DPC/ISR alene. Du kan også være ved at se på en høj værdi fra et andet tidspunkt eller på en fælles del, som flere enheder går igennem.

flowchart TB
    accTitle: Undersøg måden, der ventes på, i tidsrummet med lydudfald
    accDescr: Zoom ind på tiden før og efter lydudfaldet, og se 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 den behandling, der afsluttede ventetiden.
    A["Zoom ind omkring udfaldet"] --> B{"Trådens tilstand"}
    B -->|"Står i kø"| C["DPC og ISR"]
    B -->|"Venter på data"| D["Det, der afsluttede ventetiden"]

Figur 12: Udvælg ikke kun maksimumværdierne, men læs dem sammen med det tidsrum, hvor lydbehandlingen havde brug for at køre.

Kan årsagen ikke findes, overdrager du undersøgelsen som uafklaret. Vedlæg versionerne af OS, app, enhed og driver, trinene til at genskabe fejlen, resultaterne før og efter ændringer, tidspunkterne for udfaldene, indsamlingsprofilen og om der var advarsler om tab. Del kun ETL-filen med dem, der står for undersøgelsen, og følg virksomhedens regler.

Forudindlæsning i lydapps

Når du selv udvikler en lydapp, skal den behandling, der fylder den næste buffer, designes, så den hver gang når fristen. WASAPI har en metode, hvor appen via en hændelse får besked, når bufferen kan behandles. Exclusive-Mode Streams

MMCSS er en mekanisme, der fordeler CPU-ressourcer til tråde i tidskritisk multimediebehandling. Den har ingen funktion til at hente data fra disken i forvejen eller fjerne ventetid på låse. Også når du bruger fordelingen fra MMCSS, er der separat brug for et design, der forbereder data og mindsker ventetiden. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Det område, MMCSS dækker
    accDescr: MMCSS fordeler CPU-ressourcer til tråde i tidskritisk behandling, men forberedelse af data og mindre ventetid på låse klares med et separat design.
    M["MMCSS: fordeler CPU-ressourcer"] -.->|"Kræves separat"| D["Klargør data, mindsk ventetid"]

Figur 13: Fordeling af CPU-ressourcer og et design, der får data frem i tide, er to forskellige opgaver.

Designprincippet er at adskille den behandling, der læser fra filer eller netværk, fra den behandling, der leverer lyden. Forberedelse, hvis varighed er svær at forudsige, udføres i forvejen, og til overleveringen bruges en forhåndsallokeret buffer. På lydsiden indretter du det, så der ikke skal ventes på svar fra brugerfladen, lange låse eller synkron skrivning af logfiler.

flowchart TB
    accTitle: Adskil uforudsigelig forberedelse fra lydforsyningen
    accDescr: Et design, hvor indlæsning og lignende sker i forvejen, og de forberedte data leveres til lydbehandlingen via en buffer, så lange ventetider lige før fristen mindskes.
    A["Klargør data i forvejen"] --> B["Forhåndsallokeret overleveringsområde"]
    B --> C["Lydbehandling leverer det nødvendige"]
    C --> D["Forsyner lydens output"]

Figur 14: Flyt tidskrævende arbejde væk fra øjeblikket lige før lyden overleveres.

Hvis forberedelsessiden står stille længe, slipper lageret op trods denne adskillelse. Registrér ikke kun den gennemsnitlige behandlingstid, men også de gange, hvor der opstod lang behandling eller ventetid, og antallet af gange, forsyningen ikke lykkedes, på en måde, der ikke forstyrrer lydbehandlingen. Kontrollér den faktisk valgte bufferstørrelse og periode via API’et eller driveren, og antag ikke, at den angivne værdi blev brugt uændret. Rendering a Stream, Low Latency Audio

Både taleksemplerne og designeksemplerne er til forklaring og er hverken anbefalede indstillinger for bestemte enheder eller en garanti for, at lyden ikke falder ud i et vilkårligt miljø.

Virkningen af prioriteten Realtid

Det anbefales ikke generelt, at brugere sætter hele afspilleren til prioriteten »Realtid«. Det risikerer at forhindre anden vigtig behandling, og en højere prioritet for almindelige tråde fjerner ikke DPC/ISR eller ventetid på data og låse. I udvikling bruger man mekanismer som MMCSS og et design, der ikke bringer lange ventetider ind i lydforsyningen. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Ventetid, der består, selv med prioriteten Realtid
    accDescr: Selv hvis afspilleren får prioriteten Realtid, kan almindelige tråde ikke komme foran DPC eller ISR på samme CPU, ventetid på data og låse består, og der er også risiko for at forhindre anden vigtig behandling.
    A["Afspiller sat til Realtid"] --> B["Kommer ikke foran DPC og ISR"]
    B --> C["Ventetid på data og låse består"]
    C --> D["Risiko for at hindre anden behandling"]

Figur 15: Selv med højere prioritet består den ventetid, der forsinker genopfyldningen af lyd.

Relaterede artikler

• »Processorplanlægning« og indstillingen for baggrundstjenester i Windows
• Sikker fejlfinding af 100 % diskforbrug i Windows
• Hvorfor er RDP langsom, når forbindelsen er hurtig?

Referencer

• Microsoft Learn, Rendering a Stream. Forsyning af afspilningsbufferen, restmængde, den faktiske bufferstørrelse og definitionen af en PCM-frame.
• Microsoft Learn, Exclusive-Mode Streams. Tidspunkt for bufferforsyning og glitches i lyden, afvejning mod forsinkelse og hændelsesdrevet forsyning. Henvisningen er ikke en generel anbefaling af eksklusiv tilstand som sådan.
• Microsoft Learn, Low Latency Audio. Lydvejen i Windows, buffere, enheder, effektbehandling og forsinkelse samt afvejningerne ved lav latens.
• Microsoft Learn, CPU Analysis. Logiske CPU’er, trådtilstandene Ready/Waiting, forholdet mellem DPC/ISR og trådkørsel samt CPU-analyse i WPA.
• Microsoft Learn, Introduction to DPCs. Mekanismen, der holder interruptbehandlingen kort og udskyder det resterende arbejde til en DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Lange og hyppige DPC/ISR’er, utilstrækkelig dataforsyning og glitches i lyden. Vurderingens advarselsværdier generaliseres ikke til et sikkerhedskriterium for alle enheder.
• Microsoft Support, Fix distorted or crackling audio in Windows. Kontrol af lydforbedringer, format, drivere og andet.
• Microsoft Learn, Windows Performance Recorder. ETW-optagelse, analyse med WPA og brug af 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 af optagelse og lagring med Save, konflikter med eksisterende sessioner samt forsigtighed med personoplysninger og tabte hændelser.
• Microsoft Learn, Multimedia Class Scheduler Service. Fordeling af CPU-ressourcer til tidskritisk multimediebehandling.
• Microsoft Learn, Scheduling Priorities. Proces- og trådprioriteter samt forbehold vedrørende prioriteten Realtid.

Relaterede artikler

De nyeste artikler med de samme tags. Gå dybere ind i emnet med nært beslægtede artikler.

Relaterede emner

Emnesider, der ligger tæt på dette tema. Med artiklen som udgangspunkt kan du gå videre til relaterede ydelser og andre artikler.

Ydelser, der hænger sammen med emnet

Denne artikel er knyttet til følgende ydelsessider. Vælg den indgang, der ligger tættest på din sag.

Ofte stillede spørgsmål

Her er de spørgsmål, der ofte kommer op ved rådgivning om artiklens emne.

Hvorfor falder lyden ud, når CPU-forbruget kun er omkring 10 %?

Lyd har en frist: De næste data skal fyldes på, før de data, der afspilles nu, er brugt op. Selv om det samlede CPU-forbrug er lavt, kan fristen blive overskredet, hvis lydbehandlingen ikke kan køre i netop det øjeblik eller venter på data, den har brug for. Ikke alle lydudfald har denne årsag, og det er også nødvendigt at sammenligne med en anden outputenhed eller app.

Forsvinder lydudfaldene, hvis jeg gør lydbufferen større?

Hvis genopfyldningen kun forsinkes midlertidigt, kan en større buffer nogle gange opsuge forsinkelsen. Til gengæld bliver ventetiden, før den lagrede lyd afspilles, også længere. Indstillingen afhjælper hverken vedvarende mangel på regnekraft eller en enhed, der mister forbindelsen. I apps og drivere, hvor værdien kan ændres, noterer du den oprindelige værdi og sammenligner ét trin ad gangen.

Hvor mange millisekunders lyd er 480 frames ved 48 kHz?

Det er 480 ÷ 48000 sekunder, altså 10 millisekunder. En PCM-frame er en enhed, der samler samplene fra alle kanaler på samme tidspunkt. Værdien er længden af den lyd, som det antal frames repræsenterer, og ikke den samlede forsinkelse inklusive enheder og apps.

Er en driver med lange DPC- eller ISR-kørselstider synderen bag lydudfaldene?

Den er en kandidat, men en rangering efter kørselstid er ikke nok til at fastslå det. Sammenhold tidsrummet, hvor lydudfaldet opstod, med lydtrådens ventetid og med DPC/ISR-kørsel på samme CPU. Konkluder ikke ud fra modulnavnet alene, at en bestemt enhed eller driver er fejlbehæftet, og kontrollér også resultaterne af at ændre reproduktionsbetingelserne.

Bliver det bedre, hvis afspilleren sættes til prioriteten Realtid?

Det anbefales ikke generelt. Selv hvis en almindelig tråd får højere prioritet, kan den ikke komme foran almindelige DPC'er eller ISR'er på samme CPU, og ventetid på data eller låse forsvinder heller ikke. Udviklere bruger mekanismer som MMCSS og et design, der ikke bringer ventetid ind, og brugere sammenligner først reproduktionsbetingelserne og outputvejen.

Forfatterprofil

Profilsiden for artiklens forfatter.

Go Komura

Repræsentant for KomuraSoft LLC

Fokus på udvikling af Windows-software, teknisk rådgivning og fejlfinding, med særlig erfaring i projekter, hvor eksisterende løsninger skal bevares, og i undersøgelse af fejl, hvor årsagen er svær at spore.