Waarom hapert het geluid terwijl het CPU-gebruik laag is? — Bekeken vanuit buffers en deadlines

U luistert naar muziek en af en toe valt het geluid even weg met een korte tik. Taakbeheer toont een CPU-gebruik van ongeveer 10%, maar alleen het geluid blijft instabiel. Waarom hapert het geluid in zo’n geval, terwijl de CPU ruimte over heeft?

Ook bij een laag CPU-gebruik kan het geluid haperen als het bijvullen van de volgende audiodata de deadline niet haalt. De volgende data moet namelijk worden aangeleverd terwijl de audio die nog in de buffer staat wordt afgespeeld. Vertraging bij het bijvullen door wachten op data of locks, door DPC’s/ISR’s op de benodigde logische CPU en dergelijke, kan optreden zonder dat de CPU als geheel volledig wordt benut. Exclusive-Mode Streams, CPU Analysis

Toch kunt u alleen op basis van de tik die u hoort niet vaststellen dat het om een underrun gaat. De audiobron, de applicatie, audio-effecten, het uitvoerapparaat en andere factoren kunnen vergelijkbare symptomen veroorzaken. Vergelijk eerst met dezelfde audiobron door één voorwaarde tegelijk te wijzigen en weer terug te zetten; lukt het daarmee niet om de oorzaak te beperken, neem dan op wat er vlak voor en na de hapering gebeurt. Fix distorted or crackling audio in Windows

Dit artikel behandelt die vraag en de vragen die erop volgen: “moet ik dan gewoon de buffer groter maken?” en “wat moet ik vergelijken en wat moet ik opnemen om de oorzaak te beperken?”. Het artikel is niet bedoeld om alleen op basis van het CPU-gebruik of het geluid dat u hoort de oorzaak van een concrete storing vast te stellen.

Het artikel richt zich vooral op audio-uitvoer in Windows 11. Het vergelijkt uitvoer zoals ingebouwd, bekabeld, USB en Bluetooth, en behandelt bij muziekproductiesoftware (DAW) ook vergelijkingen voor het geval dat de applicatie of driver een bufferinstelling aanbiedt. Het ontwerp van de volledige keten voor geluidsopname en de diagnose van de draadloze communicatie per apparaat worden niet volledig behandeld.

In de uitleg gebruiken wij de gedeelde modus als basisvoorbeeld. De werkelijke route, de buffergrootte en de verwerkingsperiode verschillen per applicatie, API, driver en apparaat, en er bestaat geen scherm voor bufferinstellingen dat voor alle applicaties hetzelfde is. Low Latency Audio

Het CPU-gebruik, de resterende 10 milliseconden, de bijvultijdstippen en andere waarden in dit artikel zijn aannames ter illustratie. Het is geen verslag van metingen op een bepaalde pc waarbij het probleem werd gereproduceerd of een verbetering werd vastgesteld. De handelingen in de tweede helft zijn controlestappen die u in uw eigen omgeving uitvoert.

Het mechanisme kunt u op volgorde lezen vanaf de volgende sectie, “Audioafspeelbuffer”. De handelingen om haperingen te onderzoeken staan in “Reproductiecondities vergelijken” en “Haperingen opnemen met WPR”.

In het diagram geeft een doorgetrokken lijn een relatie aan die altijd geldt en een stippellijn een voorwaardelijke relatie (de voorwaarden staan per relatie op de detailpagina). Het volledige overzicht van de relaties (5 in totaal, met onderbouwing en zekerheid) en de definities van de belangrijkste concepten vindt u op de detailpagina van de kennisgrafiek (in het Japans). Gegevens: JSON-LD / Turtle

Audioafspeelbuffer

Alleen een opgeslagen muziekbestand laat de luidspreker nog niet klinken. De applicatie bereidt audiodata voor en levert die via Windows en de driver af bij het uitvoerapparaat. De audioafspeelbuffer is een gebied waarin de data die hierna wordt afgespeeld tijdelijk wordt opgeslagen. Terwijl het apparaat de huidige data afspeelt, bereidt de aanleverende kant de volgende data voor en vult de buffer bij. Rendering a Stream

flowchart TB
    accTitle: Een stukje audio vooruit bufferen en dan afspelen
    accDescr: Een stroom waarin voorbereide audiodata in de buffer wordt bijgevuld en de volgende data wordt voorbereid terwijl het apparaat verder afspeelt.
    A["Volgende audio voorbereiden"] --> B["Buffer bijvullen"]
    B --> C["Gebufferde audio afspelen"]
    C -.->|"Voordat het op is"| A

Afbeelding 1: Om het afspelen gaande te houden, moet het bijvullen de kant bijhouden die de audio verbruikt.

Afbeelding 1 is een conceptueel diagram dat alleen de relatie tussen bijvullen en verbruiken toont. Het stelt de meerdere buffers in de werkelijke audioroute niet voor als één fysiek gebied. Low Latency Audio

De buffer dient om kleine tijdsverschillen tussen de kant die audio voorbereidt en de kant die haar verbruikt op te vangen, zodat het afspelen ononderbroken doorgaat. De capaciteit van de buffer en de hoeveelheid nog niet afgespeelde data die er op dit moment in staat, zijn echter twee verschillende dingen. “Een capaciteit van 10 milliseconden hebben” betekent niet dat er altijd 10 milliseconden over zijn. Rendering a Stream

Hier noemen wij de tijdsbeperking om de benodigde volgende data aan te leveren voordat de data die wordt afgespeeld op is, de deadline voor het bijvullen. Audioverwerking moet “klaar zijn vóór het moment waarop het moet klinken”. “Uiteindelijk wel berekend” is niet genoeg. De toestand waarin de aanvoer te laat komt en de af te spelen data opraakt, heet een underrun en leidt tot haperingen en klikken. Ook als de data alsnog te laat aankomt, kan een onderbreking die al hoorbaar was achteraf niet meer worden opgevuld. Exclusive-Mode Streams

Route van de audiodata

In de gewone gedeelde modus ontvangt de audio-engine van Windows de data die de afspeelapplicatie heeft voorbereid, mengt meerdere geluiden en past effecten toe, en geeft het resultaat daarna door aan de driver en het uitvoerapparaat. De afspeelapplicatie is betrokken bij zowel het inlezen van de audiobron als het aanleveren aan de uitvoerbestemming, en de driver en het uitvoerapparaat brengen de data naar het apparaat en spelen haar af. Low Latency Audio

flowchart TB
    accTitle: Route van audiodata in de gedeelde modus
    accDescr: De audio-engine mengt de data die de afspeelapplicatie heeft voorbereid en past effecten toe, geeft haar door aan de driver, en het uitvoerapparaat speelt haar af.
    A["Applicatie: data voorbereiden"] --> E["Audio-engine: mengen en effecten"]
    E --> D["Driver: naar het apparaat"]
    D --> O["Uitvoerapparaat: afspelen"]

Afbeelding 2: Een voorbeeld in de gedeelde modus. De tussenliggende verwerking en buffers verschillen per API en apparaat.

Ook het apparaat kan eigen verwerking en buffers hebben, dus de totale latentie wordt niet alleen bepaald door de buffer aan de kant van de applicatie. Deze uitleg gaat uit van de route in de gedeelde modus en betekent niet dat alle API’s dezelfde verwerking doorlopen. Low Latency Audio

Bijvullen bij 10 milliseconden resterend

Stel dat er nu nog 10 milliseconden aan niet-afgespeelde data in de buffer staat. Komt het volgende bijvullen na 8 milliseconden, dan sluit het aan terwijl er nog data over is; lukt bijvullen pas na 12 milliseconden, dan is de data in dit vereenvoudigde voorbeeld op het moment van 10 milliseconden op.

flowchart TB
    accTitle: Ook bij dezelfde resterende 10 milliseconden bepaalt het moment van bijvullen de uitkomst
    accDescr: Als aanname ter illustratie toont dit dat bij 10 milliseconden resterende afspeeldata bijvullen na 8 milliseconden op tijd is, en bijvullen na 12 milliseconden pas komt als de data al op is.
    A["Nog 10 ms over"] --> B{"Volgende bijvulling"}
    B -->|"Na 8 ms"| C["Sluit aan"]
    B -->|"Na 12 ms"| D["Op na 10 ms"]

Afbeelding 3: Een voorbeeld met vereenvoudigde timing. Niet alleen óf er is bijgevuld telt, maar ook wanneer.

CPU-gebruik en vertraagd bijvullen

Het CPU-gebruik laat zien hoe druk de CPU binnen een bepaalde periode was. Dat is iets anders dan of de audioverwerking kon draaien op het moment dat dat nodig was. Ook als de CPU het grootste deel van een seconde ruimte over heeft, kan één enkel tijdvak van 12 milliseconden waarin niet kan worden bijgevuld, met die ene vertraging het geluid laten haperen. Met de verwerkingscapaciteit die daarna overblijft, kunt u een verstreken afspeelmoment niet terughalen. CPU Analysis

flowchart TB
    accTitle: Gemiddelde ruimte en één vertraagde bijvulling
    accDescr: Ook als de CPU het grootste deel van een seconde ruimte over heeft, kan één tijdvak van 12 milliseconden zonder bijvullen met die ene vertraging het geluid laten haperen.
    A["CPU bijna de hele seconde vrij"] --> B["Eén keer 12 ms niet bijgevuld"]
    B --> C["Die ene keer laat het haperen"]

Afbeelding 4: Ook met gemiddeld genoeg ruimte is een verstreken afspeelmoment niet terug te halen.

Niet alleen rekentijd gaat van de deadline af. Ook het wachten tot de verwerking kan beginnen en het wachten tot de benodigde data binnen is, tellen mee. Daarom verandert ook de onderzoeksvraag: niet alleen “hoeveel procent CPU was het?”, maar “waarop wachtte de volgende audio op het moment dat het geluid wegviel?”.

Wachten op data en locks

Stel dat de verwerking die audiodata voorbereidt, wacht tot het lezen van een bestand klaar is. Hetzelfde geldt wanneer ze wacht op een lock die door een andere verwerking in de applicatie wordt vastgehouden. De wachtende verwerking zelf gebruikt nauwelijks CPU, maar aan de kant van het apparaat gaat het afspelen door en slinkt de resterende audio. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Ook tijdens wachttijd zonder CPU-gebruik gaat het afspelen door
    accDescr: Terwijl de audioverwerking op data of locks wacht, gebruikt die verwerking geen CPU, maar het afspelen gaat door en het restant slinkt; als het bijvullen te laat komt, kan de buffer opraken.
    A["Audio wacht op data"] --> B["Die verwerking gebruikt geen CPU"]
    B --> C["Het afspelen gaat door"]
    C --> D["Te laat bijvullen: voorraad op"]

Afbeelding 5: Geen CPU gebruiken is iets anders dan het benodigde werk af hebben.

DPC, ISR en audiothreads

Een ISR is de routine die reageert op een interrupt van een apparaat. Een DPC is het mechanisme dat het resterende werk uitstelt om de interruptafhandeling kort te houden. Een gewone DPC wordt vóór gewone threads op dezelfde logische CPU uitgevoerd, en zolang een gewone DPC of ISR draait, kan die logische CPU geen gewone threads uitvoeren. Introduction to DPCs, CPU Analysis

Ook als de CPU als geheel ruimte over heeft, kan de aanvoer vertragen als deze routines lang duren of vaak optreden op de CPU die de audioverwerking nodig heeft. In een Microsoft-document over prestatieanalyse van audio en video worden ook lange DPC’s/ISR’s van drivers voor netwerk, opslag, graphics en dergelijke genoemd als mogelijke oorzaken van haperingen. Het is dus niet altijd genoeg om alleen het apparaat te onderzoeken dat het geluid weergeeft. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Wanneer reageren op apparaten de audio-uitvoering vertraagt
    accDescr: Als gewone DPC’s of ISR’s lang duren op de CPU die de audioverwerking nodig heeft, wordt de uitvoering van de thread vertraagd, wat de deadline voor het bijvullen kan beïnvloeden.
    A["DPC en ISR op dezelfde CPU"] -->|"Als ze lang duren"| B["Audio moet wachten"]
    B --> C["Volgende bijvulling vertraagd"]
    C --> D["Restant op: hapering"]

Afbeelding 6: Ook verwerking van apparaten die geen geluid weergeven, kan indirect het bijvullen van audio beïnvloeden.

Een algemene grens als “onder zoveel microseconden DPC hapert op geen enkele pc het geluid” is niet te trekken. De waarschuwingswaarden in het document over prestatiebeoordeling gelden voor de omstandigheden van die beoordeling, en wij gebruiken ze niet als veiligheidsnorm los van de werkelijke bijvuldeadline en de ruimte in de buffer. Results for the Streaming Media Performance Assessment

Buffergrootte en afspeelvertraging

Als u onder dezelfde omstandigheden meer audio vooruit buffert, vangt u tijdelijke vertragingen bij het bijvullen gemakkelijker op, maar nieuw gegenereerde audio moet dan wachten achter de audio die al gebufferd is. Een wachttijd die acceptabel is als u alleen naar muziek luistert, maakt het verschil tussen handeling en geluid storend wanneer u een keyboard bespeelt of uw stem via de microfoon bewerkt en zelf beluistert. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Bufferruimte en vertraagde reactie
    accDescr: Meer audio vooruit bufferen vangt tijdelijke vertragingen bij het bijvullen gemakkelijker op, maar verlengt ook de wachttijd tot een nieuw geluid wordt afgespeeld.
    A["Meer audio vooruit bufferen"] --> B["Vangt vertraging beter op"]
    B -->|"In ruil daarvoor"| C["Nieuw geluid wacht achteraan"]
    C --> D["Handeling tot geluid duurt langer"]

Afbeelding 7: De buffer vergroten is een afweging die ruimte schept ten koste van de reactiesnelheid.

Het is niet “hoe kleiner, hoe beter de prestaties”, maar ook niet “groter is altijd de juiste keuze”. Het doel is genoeg ruimte om haperingen te voorkomen, terwijl de benodigde reactiesnelheid behouden blijft.

De buffer vergroten schept ruimte voor tijdelijke vertragingen in de aanvoer. Als de gemiddelde aanvoer zelf het verbruik niet bijhoudt, rekt een grotere maar eindige buffer alleen de tijd op tot hij leeg is, en een apparaat dat wegvalt wordt er evenmin door opgelost. Het is ook geen aanbeveling in de zin dat de exclusieve modus alles oplost. Exclusive-Mode Streams

Audio van 480 frames bij 48 kHz

Een PCM-frame is de eenheid die de samples van alle kanalen die op hetzelfde moment worden afgespeeld, samenneemt. Bij stereo verdubbelt u dus niet het aantal frames om de tijd te berekenen. De lengte van de audio die een aantal frames voorstelt, berekent u als “aantal frames ÷ samplefrequentie”: 480 frames bij 48 kHz is 480 ÷ 48000 seconden, dus 10 milliseconden. Verhoogt u bij 48 kHz het aantal frames, dan wordt ook de tijdsduur aan audio die kan worden gebufferd langer. Rendering a Stream

Deze tijd is niet hetzelfde als de totale latentie van het indrukken van een toets tot het horen van het geluid, omdat ook de applicatie, de driver, het apparaat en andere buffers en verwerking tijd kosten. Lees ook de instelwaarden van een DAW door de eenheid en de betreffende buffer te controleren. Low Latency Audio

flowchart TB
    accTitle: Tijd berekend uit het aantal frames en totale latentie
    accDescr: De 10 milliseconden die uit 480 frames gedeeld door 48000 volgen, zijn de tijd die de buffer voorstelt; met de verwerking door applicatie, driver, apparaat en dergelijke erbij ontstaat de totale latentie van toets tot geluid.
    A["480 ÷ 48000"] --> B["10 ms die de buffer voorstelt"]
    B -->|"Plus overige verwerking"| C["Totale latentie van toets tot geluid"]

Afbeelding 8: De tijd berekend uit het aantal frames is slechts een deel van de totale latentie.

Reproductiecondities vergelijken

Beperk eerst de combinaties waarbij het probleem optreedt, en ga alleen als dat nodig is over op een gedetailleerde opname. Hieronder staan stappen om de oorzaak vast te stellen; het is geen lijst met maatregelen waarbij u alle instellingen in één keer wijzigt.

Sla uw werk op, rond belangrijke vergaderingen en geluidsopnamen af en test daarna op een volume dat uw oren niet belast. Noteer de oorspronkelijke uitvoerbestemming, de audioverbeteringen, de bufferwaarden en dergelijke, zodat u alles kunt terugzetten. Sla onderdelen over waarvoor geen instelling wordt aangeboden, en wijzig niet het register of iets anders om een instelling zichtbaar te maken.

1. Kies een vaste korte audiobron en een vaste observatietijd en controleer of het probleem onder de oorspronkelijke omstandigheden optreedt.

   Noteer de Windows-versie, de naam en versie van de applicatie, het uitvoerapparaat, het type verbinding en de driverversie. Leg ook vast wanneer, bij welke handeling en hoe vaak het geluid wegviel. Treedt het probleem onder de oorspronkelijke omstandigheden niet op, concludeer dan niet dat het verbeterd is, maar ga terug naar het vaststellen van de omstandigheden waaronder het optreedt.

2. Kies één vergelijking uit de tabel hieronder en speel af terwijl u alleen die voorwaarde wijzigt.

   Te vergelijken voorwaarde	Wat u nagaat
   Lokaal opgeslagen audio vs. afspelen via internet	Of het alleen via internet optreedt. Als het formaat of de verwerkingsroute verschilt, ook bij dezelfde inhoud, noteer dat dan ook.
   Dezelfde audiobron in een andere applicatie	Of het zich concentreert bij een bepaalde applicatie.
   Uitvoer via Bluetooth e.d. vs. ingebouwde of bekabelde uitvoer	Of het zich concentreert bij een bepaalde uitvoerroute.
   Audioverbeteringen aan vs. uit	Of het verandert in combinatie met effectverwerking.
   Huidige buffer van een DAW e.d. vs. één stap groter	Of het verandert als u meer vooruit buffert. Of ook de vertraging van handeling tot geluid acceptabel is.

3. Wilt u de audioverbeteringen vergelijken, schakel de instelling dan tijdelijk uit voor de betreffende uitvoer.

   Kies in Windows onder “Instellingen” → “Systeem” → “Geluid” de betreffende uitvoer en schakel, waar beschikbaar, “Audioverbeteringen” uit. Als de weergave of de beschikbare opties afwijken, raadpleeg dan de instructies voor die versie en dat apparaat. Fix distorted or crackling audio in Windows

4. Zet de gewijzigde instelling terug en probeer het opnieuw met dezelfde audiobron en observatietijd.

   Zet de resultaten van “oorspronkelijke omstandigheden”, “één voorwaarde gewijzigd” en “teruggezet” naast elkaar. Zet wijzigingen zonder effect terug voordat u een andere vergelijking begint. Als u combinaties van instellingen blijft veranderen, weet u niet meer wat het effect had.

5. Wilt u een andere driver proberen, controleer dan eerst de officiële distributie en de herstelmogelijkheid.

   Gebruik Windows Update of de officiële distributie van de apparaatfabrikant en noteer de versie en instellingen voor en na de wijziging. Controleer vooraf of u kunt terugkeren, en overleg op een beheerde pc met de beheerder. Beschouw het probleem niet als opgelost omdat het direct na de update één keer goed afspeelde; controleer het onder dezelfde reproductiecondities. Fix distorted or crackling audio in Windows

Wat u wilt krijgen, is een vastlegging die symptoom en omstandigheden aan elkaar koppelt, zoals “treedt op met deze applicatie bij gebruik van deze uitvoer”. Ook als u een instelling vindt die verbetering brengt, houdt u dat gescheiden van het vaststellen van de oorzaak.

flowchart TB
    accTitle: Vergelijken door één voorwaarde te wijzigen en terug te zetten
    accDescr: U controleert het optreden met dezelfde audiobron, wijzigt één voorwaarde zoals de applicatie of de uitvoer, en noteert ook het resultaat na het terugzetten.
    A["Afspelen in de originele combinatie"] --> B["Afspelen met één wijziging"]
    B --> C["Afspelen na terugzetten"]
    C --> D["Voorwaarde en tijdstip noteren"]

Afbeelding 9: Controleer liever dat voorwaarde en symptoom herhaaldelijk samenvallen dan dat het één keer beter ging.

Reproduceerbaarheid voor en na een wijziging

“Het symptoom onderdrukt”, “de omstandigheden beperkt” en “de grondoorzaak gevonden” zijn verschillende eindpunten. Leg de conclusie vast in verhouding tot wat u hebt kunnen waarnemen.

flowchart TB
    accTitle: Drie resultaten die op een verband met een voorwaarde wijzen
    accDescr: Als het probleem onder de oorspronkelijke omstandigheden optreedt, verbetert bij het wijzigen van één voorwaarde en terugkomt na het terugzetten, is dat een aanwijzing voor een verband met die voorwaarde, maar dat wordt gescheiden gehouden van het vaststellen van de oorzaak.
    A["Treedt op in het origineel"] --> B["Beter na één wijziging"]
    B --> C["Terug na terugzetten"]
    C --> D["Aanwijzing voor verband met de voorwaarde"]

Afbeelding 10: Ook als alle drie samenvallen, weet u niet meer dan dat er een aanwijzing voor een verband is.

Een laag CPU-gebruik is geen bewijs dat de deadlines van de audio zijn gehaald. Tegelijk kunt u alleen op grond van het feit dat er een hapering was, ook niet zeggen dat vertraagd bijvullen de grondoorzaak was. Vergelijk de audiobron, de verwerking in de applicatie, effecten, de uitvoerroute en dergelijke, en oordeel binnen de grenzen van wat u hebt waargenomen. Fix distorted or crackling audio in Windows

Als u een tijdelijke workaround invoert, leg dan de oorspronkelijke instelling, de wijziging, de observatietijd, of het probleem terugkwam en de acceptabele vertraging vast. Als de grondoorzaak nog niet vaststaat, noteer dat dan ook.

Haperingen opnemen met WPR

Doe dit als vergelijken van voorwaarden alleen niet genoeg is om de oorzaak te beperken, of als u de verwerking aan de driverkant wilt onderzoeken. WPR is het hulpmiddel om op te nemen, WPA het hulpmiddel om de opgeslagen tijdlijn te analyseren. Zorg voor de Windows Performance Toolkit, de rechten die nodig zijn om op te nemen en een opslaglocatie voor de ETL. Wilt u op een beheerde pc de hulpmiddelen installeren en opnemen, vraag dat dan aan de beheerder. Controleer de weergavenamen en beschikbare profielen in de geïnstalleerde versie. Windows Performance Recorder

Een ETL kan procesnamen, bestandspaden en dergelijke bevatten. Controleer vóór het opnemen de interne regels en met wie u de opname deelt, en voeg haar niet zomaar als bijlage toe op een openbare plek. Als er al een andere opnamesessie loopt, stop die dan niet op eigen houtje, maar overleg met de verantwoordelijke. WPR How-to Topics

1. Open in WPR “More Options” en kies een opnameprofiel dat bij het doel past.

   Standaardprofielen zijn onder meer “Audio glitches” en “CPU usage”. Kies een instelling waarmee u onderbrekingen in de audio en het gedrag van de CPU kunt onderzoeken. Controleer de beschikbare profielen, weergavenamen en wat er wordt verzameld in de geïnstalleerde versie, en stel niet in dat alle typen langdurig worden opgenomen. Built-in Recording Profiles

2. Start de opname voordat u de hapering reproduceert.

   Verschijnt er een bevestiging om een bestaande opname te stoppen, ga dan niet verder: annuleer het starten en overleg met de verantwoordelijke. Houd de omstandigheden gelijk aan die zonder opname en houd rekening met de mogelijkheid dat de belasting van de opname zelf het symptoom verandert. WPR How-to Topics

3. Speel af onder de omstandigheden die u bij het vergelijken hebt gevonden, en noteer het tijdstip van de hapering en de handeling.

   Neem ook een kort probleemloos stuk voor en na het symptoom mee. Als het probleem tijdens de opname niet optrad, vermeld dat dan expliciet en behandel die opname niet als een opname die de oorzaak heeft vastgelegd.

4. Beëindig na het reproduceren de opname met “Save” en sla het ETL-bestand op.

   Met “Cancel” wordt niets opgeslagen. Noteer de opslaglocatie, de reproductiecondities, of er is opgenomen en of er een waarschuwing over verloren events was. Beschouw in een opname met verloren events de onzichtbare stukken niet als normaal. WPR How-to Topics

Met het ETL-bestand en de aantekeningen over tijdstip, handeling en omstandigheden van de hapering bent u klaar om in WPA te vergelijken. Dat de opname is opgeslagen, betekent nog niet dat de benodigde events zijn vastgelegd. Controleer de inhoud in de volgende sectie, “Uitvoering en wachten rond de hapering”.

flowchart TB
    accTitle: Een korte opname maken waarin de hapering zit
    accDescr: U start de opname in WPR, reproduceert het symptoom en noteert het tijdstip, en onderzoekt de gestopte en opgeslagen opname in WPA.
    A["Opname starten in WPR"] --> B["Hapering onder gelijke condities"]
    B --> C["Tijd en handeling noteren, opslaan"]
    C --> D["In WPA inzoomen op het tijdvak"]

Afbeelding 11: Het CPU-gebruik bekijken nadat het symptoom voorbij is, is niet genoeg; u hebt een opname nodig van het tijdvak waarin het optrad.

Uitvoering en wachten rond de hapering

Zorg dat u de opgeslagen ETL en de aantekening met het tijdstip waarop het probleem optrad bij de hand hebt. Wat volgt is het startpunt voor onderzoek in WPA. Is een gedetailleerde analyse met stacks en symbolen nodig, wees dan voorzichtig met de opname en vraag de beheerder of ontwikkelaars om hulp.

1. Open de ETL in WPA en zoom, op basis van de vastgelegde audio-events en het tijdstip waarop het probleem optrad, in op het stuk voor en na de hapering.

   Bewaar ook een stuk zonder symptomen ter vergelijking. Kijk niet alleen naar de ranglijst van maximumwaarden, maar vergelijk binnen hetzelfde tijdsbereik.

2. Controleer in hetzelfde bereik “DPC/ISR” en “CPU Usage (Precise)”.

   Ontbreken de benodigde gegevens, controleer dan of het profiel ze kan vastleggen en ga terug naar de opname in WPR. Dat er niets is vastgelegd, is iets anders dan dat er geen probleem was. CPU Analysis, Built-in Recording Profiles

3. Maak onderscheid of de audiogerelateerde threads uitvoerbaar waren maar op hun beurt wachtten, of op data of iets anders wachtten.

   In het eerste geval gaat u na of DPC’s/ISR’s of dergelijke lang draaiden op de betrokken logische CPU’s. In het tweede geval volgt u met de vastgelegde events en stacks wat het wachten beëindigde. Omdat een draaiende thread ook door een interrupt kan worden onderbroken, beperkt u zich niet tot de tijd in Ready, maar legt u ook de DPC/ISR-tijdvakken eroverheen. CPU Analysis

4. Leg de tijdscorrespondentie met de hapering, de betrokken CPU’s en de resultaten van gewijzigde voorwaarden samen vast.

   Stel niet alleen op basis van de modulenaam van een lange DPC/ISR vast dat een bepaald apparaat of een bepaalde driver de oorzaak is. Mogelijk kijkt u naar een grote waarde op een ander tijdstip of naar een gemeenschappelijk onderdeel waar meerdere apparaten doorheen gaan.

flowchart TB
    accTitle: Het soort wachten onderzoeken in het tijdvak van de hapering
    accDescr: U zoomt in op het tijdvak voor en na de hapering en bekijkt de toestand van de audiothread. Wachtte die uitvoerbaar op zijn beurt, vergelijk dan met DPC’s en ISR’s op dezelfde CPU; wachtte die op data of iets anders, volg dan wat het wachten beëindigde.
    A["Inzoomen rond de hapering"] --> B{"Toestand van de thread"}
    B -->|"Wacht op beurt"| C["DPC en ISR"]
    B -->|"Wacht op data"| D["Wat het wachten beëindigde"]

Afbeelding 12: Pik niet alleen de maximumwaarden eruit, maar lees ze samen met het tijdvak waarin de audioverwerking nodig was.

Lukt het niet om de oorzaak te vinden, draag het onderzoek dan over als nog niet vastgesteld. Voeg de versies van besturingssysteem, applicatie, apparaat en driver toe, de reproductiestappen, de resultaten voor en na wijzigingen, het tijdstip van optreden, het gebruikte opnameprofiel en of er een waarschuwing over verloren events was. Deel de ETL volgens de interne regels alleen met wie het onderzoek uitvoert.

Vooruit inlezen in audioapplicaties

Als u zelf een audioapplicatie bouwt, ontwerpt u die zo dat de verwerking die de volgende buffer vult telkens de deadline haalt. WASAPI biedt een manier om via een event te horen wanneer de buffer kan worden verwerkt. Exclusive-Mode Streams

MMCSS is een mechanisme dat CPU-middelen toewijst aan threads voor multimediaverwerking met tijdsbeperkingen. Het heeft geen functie om data vooraf van schijf klaar te zetten of het wachten op locks weg te nemen. Ook als u de toewijzing door MMCSS gebruikt, is daarnaast een ontwerp nodig dat data voorbereidt en wachttijden beperkt. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Waar MMCSS voor zorgt
    accDescr: MMCSS wijst CPU-middelen toe aan threads van verwerking met tijdsbeperkingen, maar het voorbereiden van data en het beperken van wachten op locks gebeurt via een apart ontwerp.
    M["MMCSS: CPU-middelen toewijzen"] -.->|"Apart nodig"| D["Data voorbereiden, wachten beperken"]

Afbeelding 13: CPU-middelen toewijzen en zo ontwerpen dat data op tijd klaarstaat, zijn twee verschillende taken.

Het ontwerpprincipe is om de verwerking die uit bestanden of het netwerk leest, te scheiden van de verwerking die de audio aanlevert. Doe voorbereidingen waarvan de duur moeilijk te voorspellen is vooraf, en gebruik voor de overdracht vooraf toegewezen buffers. Zorg dat de audiokant niet hoeft te wachten op een reactie van de UI, lange locks of synchrone logschrijfacties.

flowchart TB
    accTitle: Onvoorspelbare voorbereiding scheiden van de audioaanvoer
    accDescr: Een ontwerp waarin inlezen en dergelijke vooraf gebeurt en de voorbereide data via een buffer aan de audioverwerking wordt doorgegeven, zodat lang wachten vlak voor de deadline afneemt.
    A["Data vooraf voorbereiden"] --> B["Vooraf toegewezen overdrachtsgebied"]
    B --> C["Audio geeft benodigde deel door"]
    C --> D["Aanvoer naar audio-uitvoer"]

Afbeelding 14: Haal tijdrovend werk weg van het moment vlak voor de overdracht van de audio.

Als de voorbereidende kant lang stilvalt, raakt de voorraad ook met deze scheiding op. Leg niet alleen de gemiddelde verwerkingstijd vast, maar ook de keren dat lange verwerking of lang wachten optrad en hoe vaak er niet kon worden aangeleverd, op een manier die de audioverwerking niet hindert. Controleer de werkelijk gekozen buffergrootte en periode via de API of de driver, en ga er niet van uit dat de opgegeven waarde ongewijzigd is overgenomen. Rendering a Stream, Low Latency Audio

Zowel de getallenvoorbeelden als de ontwerpvoorbeelden dienen ter illustratie; het zijn geen aanbevolen instelwaarden voor een bepaald apparaat en geen garantie dat het geluid in elke omgeving zonder haperingen blijft.

Effect van realtimeprioriteit

Wij raden gebruikers niet als algemene regel aan om de hele speler op de prioriteit “Realtime” te zetten. Er is een risico dat dit andere belangrijke verwerking verstoort, en het verhogen van de prioriteit van een gewone thread neemt DPC’s/ISR’s en het wachten op data of locks niet weg. Bij ontwikkeling worden mechanismen zoals MMCSS gebruikt, samen met een ontwerp dat geen lange wachttijden in de audioaanvoer brengt. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Wachten dat blijft, ook met realtimeprioriteit
    accDescr: Ook als u de speler op realtimeprioriteit zet, kunnen gewone threads niet voorgaan op DPC’s en ISR’s op dezelfde CPU, blijft het wachten op data en locks bestaan, en is er bovendien een risico dat andere belangrijke verwerking wordt verstoord.
    A["Speler op realtimeprioriteit"] --> B["Gaat niet voor DPC en ISR"]
    B --> C["Wachten op data en locks blijft"]
    C --> D["Risico op verstoring van andere taken"]

Afbeelding 15: Ook met een hogere prioriteit blijft het wachten bestaan dat het bijvullen van audio vertraagt.

Gerelateerde artikelen

• “Processorplanning” in Windows en de instelling voor achtergrondservices
• Schijfgebruik van 100% in Windows veilig uitzoeken
• Waarom is RDP traag terwijl de verbinding snel is?

Bronnen

• Microsoft Learn, Rendering a Stream. Aanvoer naar de afspeelbuffer, resterende hoeveelheid, werkelijke buffergrootte en de definitie van een PCM-frame.
• Microsoft Learn, Exclusive-Mode Streams. Tijdstip van bufferaanvoer en audioglitches, afweging met latentie en eventgestuurde aanvoer. Dit is geen algemene aanbeveling voor de exclusieve modus zelf.
• Microsoft Learn, Low Latency Audio. De audioroute in Windows, buffers, apparaten, effectverwerking en latentie, en de afwegingen bij lage latentie.
• Microsoft Learn, CPU Analysis. Logische CPU’s, de toestanden Ready/Waiting van threads, de relatie tussen DPC/ISR en threaduitvoering, en CPU-analyse in WPA.
• Microsoft Learn, Introduction to DPCs. Het mechanisme dat interruptafhandeling kort houdt en het resterende werk aan een DPC overdraagt.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Lange of frequente DPC’s/ISR’s, tekort aan data-aanvoer en audioglitches. De waarschuwingswaarden van de beoordeling worden niet veralgemeend tot veiligheidsnorm voor alle apparaten.
• Microsoft Support, Fix distorted or crackling audio in Windows. Controle van audioverbeteringen, formaat, drivers en dergelijke.
• Microsoft Learn, Windows Performance Recorder. ETW-opname, analyse met WPA en gebruik van de Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options in WPR en standaardprofielen zoals Audio glitches en CPU usage.
• Microsoft Learn, WPR How-to Topics. Opname starten en opslaan met Save, conflicten met bestaande sessies, en aandachtspunten voor persoonsgegevens en verloren events.
• Microsoft Learn, Multimedia Class Scheduler Service. Toewijzing van CPU-middelen aan multimediaverwerking met tijdsbeperkingen.
• Microsoft Learn, Scheduling Priorities. Proces- en threadprioriteiten en aandachtspunten bij realtimeprioriteit.

Gerelateerde artikelen

Recente artikelen met dezelfde tags. Verdiep uw kennis met nauw verwante onderwerpen.

Gerelateerde onderwerpen

Onderwerppagina’s die dicht bij dit thema liggen. Vanuit dit artikel kunt u doorklikken naar verwante diensten en andere artikelen.

Diensten bij dit thema

Dit artikel sluit aan op de volgende dienstpagina’s. Kies een ingang die dicht bij uw vraag ligt.

Veelgestelde vragen

Vragen die tijdens een adviesgesprek vaak over het thema van dit artikel worden gesteld.

Waarom hapert het geluid terwijl het CPU-gebruik maar ongeveer 10% is?

Audio heeft een deadline: de volgende data moet zijn bijgevuld voordat de data die nu wordt afgespeeld op is. Ook als het totale CPU-gebruik laag is, kan het bijvullen te laat komen als de audioverwerking op dat moment niet kon draaien of op benodigde data wachtte. Niet elke hapering heeft deze oorzaak; vergelijken met een ander uitvoerapparaat of een andere applicatie is ook nodig.

Verhelpt een grotere audiobuffer de haperingen?

Als het bijvullen tijdelijk vertraagd is, kan een grotere buffer dat soms opvangen. Maar ook de wachttijd tot de gebufferde audio wordt afgespeeld neemt toe. Het is geen instelling die een aanhoudend tekort aan verwerkingscapaciteit of een wegvallend apparaat oplost. Noteer bij applicaties en drivers waarin u de waarde kunt wijzigen eerst de oorspronkelijke waarde en vergelijk stap voor stap.

Hoeveel milliseconden audio zijn 480 frames bij 48 kHz?

Het is 480 ÷ 48000 seconden, dus 10 milliseconden. Een PCM-frame is de eenheid die de samples van alle kanalen op hetzelfde moment samenneemt. Deze waarde is de lengte van de audio die dat aantal frames voorstelt, niet de totale latentie inclusief apparaat en applicatie.

Is een driver met lange DPC- of ISR-uitvoeringstijden de boosdoener achter haperingen?

Hij is een kandidaat, maar alleen op basis van een ranglijst van uitvoeringstijden kunt u dat niet vaststellen. Leg het tijdvak van de hapering naast het wachten van de audiothread en de uitvoering van DPC’s/ISR’s op dezelfde CPU. Concludeer niet alleen op basis van een modulenaam dat een bepaald apparaat of een bepaalde driver defect is, en controleer ook de resultaten na het wijzigen van de reproductiecondities.

Helpt het om de speler op realtimeprioriteit te zetten?

Dat raden wij niet als algemene regel aan. Het verhogen van de prioriteit van een gewone thread laat die niet voorgaan op gewone DPC’s en ISR’s op dezelfde CPU, en het wachten op data of locks verdwijnt er ook niet door. Ontwikkelaars gebruiken mechanismen zoals MMCSS en een ontwerp dat geen wachttijden introduceert; gebruikers vergelijken eerst de reproductiecondities en de uitvoerroute.

Profiel van de auteur

De profielpagina van de auteur van dit artikel.

Go Komura

Vertegenwoordiger van KomuraSoft LLC

Richt zich op Windows-softwareontwikkeling, technisch advies en foutanalyse, en is vooral sterk in projecten waarin bestaande assets behouden blijven en in storingsonderzoek waarbij de oorzaak moeilijk zichtbaar is.