De ce se taie sunetul deși utilizarea CPU este scăzută? — O explicație prin buffer și termenul-limită

Ascultați muzică și, din când în când, sunetul se taie cu un „pac” scurt. Managerul de activități arată o utilizare a CPU de aproximativ 10%, dar numai sunetul este instabil. De ce se taie sunetul în astfel de situații, deși CPU-ul are rezervă?

Chiar dacă utilizarea CPU este scăzută, sunetul se poate tăia dacă reumplerea cu următoarele date audio nu se încadrează în termenul-limită. Motivul este că datele următoare trebuie predate cât timp se redă sunetul rămas în buffer. Reumplerea poate întârzia din cauza așteptării după date sau blocări, a DPC/ISR pe CPU-ul logic necesar și a altor factori, iar acest lucru se întâmplă chiar și fără ca CPU-ul în ansamblu să fie folosit la capacitate maximă. Exclusive-Mode Streams, CPU Analysis

Totuși, numai după „pac”-ul auzit nu se poate afirma cu certitudine că este vorba de un underrun. Simptome asemănătoare pot fi cauzate și de sursa audio, de aplicație, de efectele audio, de dispozitivul de ieșire și de altele. Mai întâi, cu aceeași sursă audio, comparați schimbând condițiile pe rând și readucându-le la starea inițială, iar dacă nici așa nu reușiți să restrângeți cauzele, înregistrați ce se întâmplă înainte și după căderea de sunet. Fix distorted or crackling audio in Windows

Acest articol tratează această întrebare și pe cele care decurg din ea: „E suficient să măresc bufferul?” și „Ce trebuie comparat și ce trebuie înregistrat ca să restrâng cauzele?”. Articolul nu stabilește cauza unei defecțiuni concrete doar pe baza utilizării CPU sau a sunetului auzit.

Ne referim în principal la ieșirea audio în Windows 11. Comparăm ieșiri integrate, cu fir, USB, Bluetooth și altele, iar pentru software-ul de producție muzicală (DAW) tratăm și comparațiile pentru cazurile în care aplicația sau driverul oferă setări de buffer. Proiectarea întregului lanț de înregistrare audio și diagnosticarea comunicației wireless a fiecărui dispozitiv nu sunt acoperite exhaustiv.

În explicații folosim modul partajat ca exemplu de bază. Traseul real, dimensiunea bufferului și perioada de procesare diferă în funcție de aplicație, API, driver și dispozitiv și nu există un ecran de setări ale bufferului comun tuturor aplicațiilor. Low Latency Audio

Utilizarea CPU, restul de 10 milisecunde, momentele reumplerii și celelalte valori prezentate aici sunt ipoteze pentru explicație. Nu sunt rezultatele unor măsurători ale reproducerii sau ale ameliorării pe un anumit PC. Operațiile din a doua parte a articolului sunt pași de verificare pe care îi efectuați în propriul mediu.

Mecanismul poate fi citit în ordine, începând cu secțiunea următoare, „Bufferul de redare audio”. Operațiile pentru investigarea căderilor de sunet se află în „Compararea condițiilor de reproducere” și „Înregistrarea căderilor de sunet cu WPR”.

În diagramă, linia continuă marchează o relație care este întotdeauna valabilă, iar linia punctată una condiționată (condițiile sunt indicate pentru fiecare relație pe pagina de detalii). Lista completă a relațiilor (5 în total, cu dovezi și grad de certitudine) și definițiile conceptelor principale sunt reunite în pagina de detalii a hărții cunoștințelor (în japoneză). Date: JSON-LD / Turtle

Bufferul de redare audio

Simpla salvare a unui fișier muzical nu face difuzoarele să sune. Aplicația pregătește datele audio și le livrează, prin Windows și driver, către dispozitivul de ieșire. Bufferul de redare audio este zona în care sunt păstrate temporar datele care urmează să fie redate. Cât timp dispozitivul redă datele curente, partea care furnizează datele le pregătește pe următoarele și reumple bufferul. Rendering a Stream

flowchart TB
    accTitle: Sunetul este acumulat puțin în avans, apoi redat
    accDescr: Fluxul în care datele audio pregătite reumplu bufferul, iar cât timp dispozitivul redă, se pregătesc datele următoare.
    A["Pregătirea sunetului următor"] --> B["Reumplerea bufferului"]
    B --> C["Redarea sunetului acumulat"]
    C -.->|"Înainte să se epuizeze"| A

Figura 1: Pentru ca redarea să continue, reumplerea trebuie să țină pasul cu partea care consumă sunetul.

Figura 1 este o diagramă conceptuală care arată doar relația dintre reumplere și consum. Nu este o diagramă care consideră că mai multe buffere din traseul audio real formează fizic o singură zonă. Low Latency Audio

Rolul bufferului este să absoarbă decalajele scurte de timp dintre partea care pregătește sunetul și cea care îl folosește și să asigure astfel o redare continuă. Totuși, capacitatea bufferului și cantitatea de date încă neredate aflate acum în el sunt lucruri diferite. Faptul că „are o capacitate de 10 milisecunde” nu înseamnă că în el rămân mereu 10 milisecunde de sunet. Rendering a Stream

Aici numim termen-limită de reumplere constrângerea de timp de a livra datele următoare necesare înainte ca datele aflate în redare să se epuizeze. Procesarea audio trebuie să fie „gata până la momentul în care sunetul trebuie să se audă”. Nu este suficient că „până la urmă calculul s-a terminat”. Starea în care furnizarea nu se încadrează în timp și datele de redat se epuizează se numește underrun și duce la căderi de sunet și pocnituri. Chiar dacă datele sosesc cu întârziere, golul deja auzit nu mai poate fi umplut ulterior. Exclusive-Mode Streams

Traseul datelor audio

În modul partajat obișnuit, motorul audio Windows primește datele pregătite de aplicația de redare, mixează mai multe sunete sau aplică efecte, apoi le transmite driverului și dispozitivului de ieșire. Aplicația de redare participă atât la citirea sursei audio, cât și la furnizarea datelor către ieșire, iar driverul și dispozitivul de ieșire transportă datele spre dispozitiv și le redau. Low Latency Audio

flowchart TB
    accTitle: Traseul datelor audio în modul partajat
    accDescr: Datele pregătite de aplicația de redare sunt mixate și prelucrate cu efecte de motorul audio, transmise driverului și redate de dispozitivul de ieșire.
    A["Aplicația de redare: pregătește datele"] --> E["Motorul audio: mixare, efecte"]
    E --> D["Driverul: transport spre dispozitiv"]
    D --> O["Dispozitivul de ieșire: redare"]

Figura 2: Exemplu pentru modul partajat. Procesările și bufferele intermediare diferă în funcție de API și de dispozitiv.

Și dispozitivul poate avea propriile procesări și buffere, așa că latența totală nu este determinată doar de bufferul aplicației. Această explicație pornește de la traseul modului partajat și nu înseamnă că orice API trece prin aceleași procesări. Low Latency Audio

Reumplerea când mai rămân 10 milisecunde

Să presupunem că în buffer mai rămân acum 10 milisecunde de date neredate. Dacă următoarea reumplere are loc după 8 milisecunde, sunetul continuă cât timp mai există rest, dar dacă bufferul nu poate fi reumplut până la 12 milisecunde, în acest exemplu simplificat datele se epuizează la 10 milisecunde.

flowchart TB
    accTitle: La același rest de 10 milisecunde, rezultatul depinde de momentul reumplerii
    accDescr: Arată, ca ipoteză explicativă, că pentru 10 milisecunde de date rămase reumplerea după 8 milisecunde ajunge la timp, iar cea după 12 milisecunde vine după epuizarea datelor.
    A["Rămân 10 milisecunde"] --> B{"Următoarea reumplere"}
    B -->|"După 8 milisecunde"| C["Sunetul continuă"]
    B -->|"După 12 milisecunde"| D["Se epuizează la 10 milisecunde"]

Figura 3: Exemplu cu timp simplificat. Contează nu doar dacă reumplerea a reușit, ci și când a reușit.

Utilizarea CPU și întârzierea reumplerii

Utilizarea CPU arată cât de ocupat a fost procesorul într-un anumit interval de timp. Dacă procesarea audio a putut rula exact în momentul în care era nevoie de ea este cu totul altă întrebare. Chiar dacă CPU-ul are rezervă în cea mai mare parte a unei secunde, un singur interval de 12 milisecunde fără reumplere poate fi suficient pentru ca sunetul să se taie. Rezerva de capacitate de procesare rămasă ulterior nu poate recupera momentul de redare care a trecut deja. CPU Analysis

flowchart TB
    accTitle: Rezerva medie și o singură întârziere a reumplerii
    accDescr: Chiar dacă CPU-ul are rezervă în cea mai mare parte a unei secunde, un singur interval de 12 milisecunde fără reumplere poate face ca sunetul să se taie.
    A["CPU liber cea mai mare parte a secundei"] --> B["O singură dată, 12 milisecunde fără reumplere"]
    B --> C["Acea singură dată taie sunetul"]

Figura 4: Chiar și cu rezervă medie, momentul de redare trecut nu mai poate fi recuperat.

Timpul până la termenul-limită nu este consumat doar de calcul. Intră aici și așteptarea până la începerea procesării, și așteptarea până la sosirea datelor necesare. De aceea, se schimbă și întrebarea investigației: nu doar „la cât la sută a fost CPU-ul”, ci și „ce aștepta sunetul următor în momentul în care sunetul s-a tăiat”.

Așteptarea datelor și a blocărilor

Să presupunem că procesarea care pregătește datele audio așteaptă terminarea citirii unui fișier. La fel se întâmplă când așteaptă o blocare deținută de o altă procesare din aplicație. Procesarea care așteaptă folosește ea însăși puțin CPU, dar pe partea dispozitivului redarea continuă, iar sunetul rămas scade. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Redarea continuă și în timpul așteptărilor care nu folosesc CPU
    accDescr: Cât timp procesarea audio așteaptă date sau o blocare, ea nu folosește CPU, dar redarea continuă și restul scade, iar dacă reumplerea întârzie, bufferul se poate epuiza.
    A["Procesarea audio așteaptă date"] --> B["Ea nu folosește CPU"]
    B --> C["Între timp redarea continuă"]
    C --> D["Reumplere întârziată, stoc epuizat"]

Figura 5: A nu folosi CPU și a fi terminat munca necesară sunt lucruri diferite.

DPC, ISR și firul audio

ISR este procesarea care răspunde la o întrerupere de la un dispozitiv. DPC este mecanismul care amână restul muncii pentru mai târziu, pentru ca procesarea întreruperii să rămână scurtă. DPC-urile obișnuite rulează înaintea firelor de execuție obișnuite de pe același CPU logic, iar cât timp rulează DPC-uri sau ISR-uri obișnuite, firele obișnuite nu pot rula pe acel CPU logic. Introduction to DPCs, CPU Analysis

Chiar dacă CPU-ul are rezervă în ansamblu, furnizarea poate întârzia dacă acestea se prelungesc sau apar des pe CPU-ul necesar procesării audio. Materialele Microsoft de analiză a performanței audio și video enumeră printre cauzele posibile ale căderilor de sunet și DPC/ISR lungi provenite de la drivere de rețea, stocare, grafică și altele. Nu este neapărat suficient să verificați doar dispozitivul care redă sunetul. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Când răspunsul la un dispozitiv întârzie execuția audio
    accDescr: Dacă DPC-urile sau ISR-urile obișnuite se prelungesc pe CPU-ul necesar procesării audio, execuția firului întârzie și poate afecta termenul-limită de reumplere.
    A["DPC și ISR pe același CPU"] -->|"Dacă se prelungesc"| B["Execuția audio așteaptă"]
    B --> C["Reumplerea sunetului următor întârzie"]
    C --> D["Restul se epuizează, sunetul se taie"]

Figura 6: Și procesările din afara dispozitivului care redă sunetul pot influența indirect reumplerea audio.

Nu se poate trasa o limită comună de tipul „dacă DPC-ul durează sub atâtea microsecunde, sunetul nu se va tăia pe niciun PC”. Valorile de avertizare din materialele de evaluare a performanței sunt valabile pentru condițiile acelei evaluări, iar noi nu le transformăm în criterii de siguranță separat de termenul-limită real de reumplere și de rezerva bufferului. Results for the Streaming Media Performance Assessment

Dimensiunea bufferului și latența redării

Dacă, în aceleași condiții, acumulați mai mult sunet în avans, întârzierile temporare ale reumplerii sunt absorbite mai ușor, însă sunetul nou creat așteaptă în spatele celui deja acumulat. O așteptare acceptabilă când doar ascultați muzică devine supărătoare când cântați la claviatură sau când procesați vocea din microfon și o ascultați chiar dumneavoastră, fiindcă se simte decalajul dintre acțiune și sunet. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Rezerva bufferului și întârzierea reacției
    accDescr: Dacă acumulați mai mult sunet în avans, întârzierile temporare ale reumplerii sunt absorbite mai ușor, dar crește și timpul de așteptare până la redarea sunetului nou.
    A["Acumulați mai mult sunet în avans"] --> B["Întârzierile se absorb mai ușor"]
    B -->|"În schimb"| C["Sunetul nou așteaptă în spate"]
    C --> D["Sunetul vine mai târziu după acțiune"]

Figura 7: Mărirea bufferului este o ajustare care creează rezervă în schimbul vitezei de reacție.

Nu este valabil nici „cu cât mai mic, cu atât mai performant”, nici „cu cât mai mare, cu atât mai corect”. Păstrați viteza de reacție necesară și, în același timp, asigurați rezerva care împiedică tăierea sunetului.

Mărirea bufferului creează rezervă pentru întârzierile temporare ale furnizării. Dacă furnizarea medie în sine nu ține pasul cu consumul, mărirea unui buffer finit doar prelungește timpul până la epuizare și nu rezolvă nici deconectarea dispozitivului. Nu este nici o recomandare în sensul că modul exclusiv ar rezolva totul. Exclusive-Mode Streams

Sunet de 480 de cadre la 48 kHz

Un cadru PCM este unitatea care grupează eșantioanele tuturor canalelor redate în același moment. Faptul că semnalul este stereo nu înseamnă că dublați numărul de cadre pentru a calcula timpul. Durata sunetului reprezentată de un număr de cadre se obține ca „număr de cadre ÷ rata de eșantionare”: la 48 kHz, 480 de cadre înseamnă 480 ÷ 48000 de secunde, adică 10 milisecunde. Dacă măriți numărul de cadre păstrând 48 kHz, crește și durata sunetului care poate fi acumulat. Rendering a Stream

Acest timp este diferit de latența totală de la apăsarea unei clape până când sunetul se aude, deoarece există și timpul aplicației, al driverului, al dispozitivului, al altor buffere și procesări. Citiți și valorile setărilor din DAW verificând unitatea de măsură și bufferul la care se referă. Low Latency Audio

flowchart TB
    accTitle: Timpul calculat din numărul de cadre și latența totală
    accDescr: Cele 10 milisecunde obținute împărțind 480 de cadre la 48000 sunt timpul reprezentat de buffer, iar latența totală de la clapă la sunet include și procesările din aplicație, driver, dispozitiv și altele.
    A["480 ÷ 48000"] --> B["10 milisecunde în buffer"]
    B -->|"Se adaugă alte procesări"| C["Latența totală de la clapă la sunet"]

Figura 8: Timpul calculat din numărul de cadre este doar o parte din latența totală.

Compararea condițiilor de reproducere

Restrângeți mai întâi combinațiile în care problema se reproduce și treceți la o înregistrare detaliată doar dacă este necesar. Ce urmează sunt pași pentru verificarea cauzei, nu o listă de remedii în care toate modificările de setări se aplică deodată.

Salvați-vă munca, încheiați ședințele sau înregistrările reale și abia apoi testați, la un volum care nu vă obosește urechile. Notați dispozitivul de ieșire inițial, îmbunătățirile audio, valorile bufferului și altele, ca să puteți reveni. Săriți peste elementele pentru care nu există setări și nu modificați registrul Windows sau altceva doar ca să apară astfel de setări.

1. Stabiliți o sursă audio scurtă și un timp de observare pe care le păstrați neschimbate, apoi verificați dacă problema se reproduce în condițiile inițiale.

   Notați versiunea Windows, numele și versiunea aplicației, dispozitivul de ieșire, modul de conectare și versiunea driverului. Notați și momentul, operația efectuată și numărul căderilor de sunet. Dacă problema nu se reproduce în condițiile inițiale, nu considerați că s-a ameliorat, ci reveniți la identificarea condițiilor în care se reproduce.

2. Alegeți din tabelul de mai jos o singură comparație și redați sunetul schimbând doar acea condiție.

   Condiția comparată	Ce verificați
   Sursa audio salvată local și redarea prin rețea	Dacă problema apare doar la redarea prin rețea. Dacă formatul sau traseul de procesare diferă chiar și la același conținut, notați și acest lucru.
   Aceeași sursă audio redată în altă aplicație	Dacă problema este concentrată într-o anumită aplicație.
   Ieșire Bluetooth sau similară față de ieșirea integrată sau cu fir	Dacă problema este concentrată pe un anumit traseu de ieșire.
   Îmbunătățiri audio activate și dezactivate	Dacă rezultatul se schimbă în combinație cu procesarea efectelor.
   Bufferul actual din DAW sau din alte aplicații și o valoare cu o treaptă mai mare	Dacă rezultatul se schimbă când măriți rezerva acumulată în avans. Dacă întârzierea dintre acțiune și sunet rămâne și ea acceptabilă.

3. Dacă comparați îmbunătățirile audio, dezactivați temporar setarea pentru ieșirea respectivă.

   În Windows, deschideți „Setări” → „Sistem” → „Sunet”, selectați ieșirea respectivă și, acolo unde opțiunea este disponibilă, dezactivați „Îmbunătățiri audio”. Dacă afișarea sau existența elementelor diferă, consultați instrucțiunile pentru versiunea și dispozitivul dumneavoastră. Fix distorted or crackling audio in Windows

4. Readuceți setarea modificată la valoarea inițială și încercați din nou cu aceeași sursă audio și același timp de observare.

   Puneți una lângă alta rezultatele pentru „condițiile inițiale”, „condițiile cu o singură modificare” și „condițiile readuse la starea inițială”. Readuceți la starea inițială modificările fără efect înainte de a trece la altă comparație. Dacă schimbați încontinuu combinațiile de setări, nu veți mai ști ce anume a funcționat.

5. Dacă încercați să schimbați driverul, faceți-o după ce verificați sursa oficială de distribuție și metoda de recuperare.

   Folosiți Windows Update sau distribuția oficială a producătorului dispozitivului și notați versiunile și setările dinainte și de după modificare. Verificați în prealabil dacă puteți reveni la starea anterioară, iar pe PC-urile administrate consultați administratorul. Nu considerați problema rezolvată doar pentru că, imediat după actualizare, sunetul a putut fi redat o dată; verificați în aceleași condiții de reproducere. Fix distorted or crackling audio in Windows

Rezultatul urmărit este o evidență care pune în corespondență simptomul cu condițiile, de exemplu „se reproduce în această aplicație, când folosesc această ieșire”. Chiar dacă găsiți o setare cu care situația se ameliorează, țineți acest lucru separat de stabilirea cauzei.

flowchart TB
    accTitle: Comparație cu o singură condiție schimbată și apoi readusă
    accDescr: Se verifică reproducerea cu aceeași sursă audio, se schimbă o singură condiție, de exemplu aplicația sau ieșirea, și se notează și rezultatul după revenirea la starea inițială.
    A["Redare în combinația inițială"] --> B["Redare cu o condiție schimbată"]
    B --> C["Redare după revenire"]
    C --> D["Notați condiția și momentul tăierii"]

Figura 9: Mai important decât o ameliorare izolată este să confirmați că o condiție și simptomul corespund în mod repetat.

Reproductibilitatea înainte și după schimbarea condițiilor

„Simptomul a putut fi atenuat”, „condițiile au putut fi restrânse” și „cauza principală a putut fi identificată” sunt etape diferite. Notați concluzia în limitele a ceea ce ați putut observa.

flowchart TB
    accTitle: Trei rezultate care indică o legătură cu condiția
    accDescr: Dacă problema se reproduce în condițiile inițiale, se ameliorează când schimbați o condiție și se reproduce din nou după revenire, aveți un indiciu că există o legătură cu acea condiție, dar îl țineți separat de stabilirea cauzei.
    A["Se reproduce în condițiile inițiale"] --> B["O modificare o ameliorează"]
    B --> C["La revenire se reproduce"]
    C --> D["Indiciu de legătură cu condiția"]

Figura 10: Chiar dacă toate trei sunt îndeplinite, aflați doar un indiciu de legătură.

O utilizare scăzută a CPU nu este o dovadă că termenul-limită audio a fost respectat. În același timp, simplul fapt că a existat o cădere de sunet nu permite afirmația că întârzierea reumplerii a fost cauza principală. Comparați sursa audio, procesarea din aplicație, efectele, traseul de ieșire și altele și judecați în limitele a ceea ce ați observat. Fix distorted or crackling audio in Windows

Când adoptați o soluție de ocolire provizorie, notați setările inițiale, modificarea făcută, timpul de observare, dacă problema a reapărut și latența acceptabilă. Dacă nu ați stabilit cauza principală, notați și acest lucru.

Înregistrarea căderilor de sunet cu WPR

Faceți acest pas când comparația condițiilor nu este suficientă pentru a restrânge cauzele sau când investigați procesarea din partea driverului. WPR este instrumentul pentru înregistrare, iar WPA, pentru analiza axei de timp salvate. Pregătiți Windows Performance Toolkit, drepturile necesare înregistrării și o locație pentru salvarea fișierului ETL. Când instalați instrumentele și înregistrați pe un PC administrat, apelați la administrator. Verificați denumirile afișate și profilurile disponibile în versiunea instalată. Windows Performance Recorder

Fișierele ETL pot conține nume de procese, căi de fișiere și altele. Înainte de înregistrare, verificați regulile interne și persoanele cu care veți partaja fișierul și nu îl atașați ca atare în locuri publice. Dacă rulează deja o altă sesiune de înregistrare, nu o opriți din proprie inițiativă, ci întrebați persoana responsabilă. WPR How-to Topics

1. Deschideți „More Options” în WPR și alegeți profilul de înregistrare potrivit scopului.

   Printre profilurile standard se află „Audio glitches” și „CPU usage”. Alegeți setări care vă permit să investigați discontinuitățile sunetului și activitatea CPU. Verificați în versiunea instalată profilurile disponibile, denumirile lor și ce colectează și nu configurați o înregistrare îndelungată a tuturor tipurilor. Built-in Recording Profiles

2. Porniți înregistrarea înainte de a reproduce căderea de sunet.

   Dacă apare o confirmare pentru oprirea unei înregistrări existente, nu continuați: anulați pornirea și întrebați persoana responsabilă. Păstrați aceleași condiții ca fără înregistrare și țineți cont că sarcina înregistrării însăși poate schimba simptomul. WPR How-to Topics

3. Redați sunetul în condițiile găsite prin comparație și notați momentul tăierii și operația efectuată.

   Includeți și puțin din intervalele fără probleme dinaintea și de după simptom. Dacă problema nu s-a reprodus, menționați explicit acest lucru pentru înregistrarea respectivă și nu o tratați ca pe o înregistrare care a surprins cauza.

4. După reproducere, încheiați înregistrarea cu „Save” și salvați fișierul ETL.

   Cu „Cancel” nu se salvează nimic. Notați locația de salvare, condițiile de reproducere, dacă există înregistrarea și dacă a apărut un avertisment privind evenimente pierdute. Într-o înregistrare cu pierderi, nu considerați normale intervalele care nu se văd. WPR How-to Topics

Când aveți fișierul ETL și notițele despre momentul, operația și condițiile căderii de sunet, sunteți gata pentru corelarea în WPA. Simplul fapt că ați salvat înregistrarea nu garantează că evenimentele necesare au fost colectate. Conținutul se verifică în secțiunea următoare, „Execuția și așteptările din jurul căderii de sunet”.

flowchart TB
    accTitle: O înregistrare scurtă care include căderea de sunet
    accDescr: Porniți înregistrarea în WPR, reproduceți simptomul și notați momentul, apoi analizați în WPA înregistrarea oprită și salvată.
    A["Pornirea înregistrării în WPR"] --> B["Reproducerea tăierii în aceleași condiții"]
    B --> C["Notați momentul și operația, salvați"]
    C --> D["Mărirea intervalului din jur în WPA"]

Figura 11: Utilizarea CPU privită după ce simptomul a trecut nu este suficientă; aveți nevoie de înregistrarea intervalului în care a apărut simptomul.

Execuția și așteptările din jurul căderii de sunet

Pregătiți fișierul ETL salvat și notițele cu momentul reproducerii. Ce urmează este un punct de plecare pentru investigația în WPA. Dacă devine necesară o analiză detaliată, cu stive și simboluri, tratați înregistrarea cu grijă și apelați la administrator sau la dezvoltatori.

1. Deschideți fișierul ETL în WPA și, pe baza evenimentelor audio colectate și a momentului reproducerii, măriți intervalul dinaintea și de după căderea de sunet.

   Păstrați pentru comparație și intervale fără simptom. Nu vă uitați doar la clasamentul valorilor maxime, ci comparați pe același interval de timp.

2. În același interval, verificați „DPC/ISR” și „CPU Usage (Precise)”.

   Dacă lipsesc datele necesare, verificați dacă profilul le poate colecta și reveniți la înregistrarea cu WPR. Lipsa înregistrării și lipsa unei probleme sunt lucruri diferite. CPU Analysis, Built-in Recording Profiles

3. Stabiliți dacă firele de execuție legate de sunet erau gata de rulare, dar își așteptau rândul, sau dacă așteptau date ori altceva.

   În primul caz, corelați dacă pe CPU-ul logic implicat au rulat timp îndelungat DPC/ISR sau altele. În al doilea caz, urmăriți cu ajutorul evenimentelor și stivelor colectate ce a încheiat așteptarea. Deoarece și un fir aflat în execuție poate fi suspendat de o întrerupere, nu vă limitați la timpul în starea Ready, ci suprapuneți și intervalele DPC/ISR. CPU Analysis

4. Notați împreună corespondența în timp cu căderea de sunet, CPU-urile implicate și rezultatele obținute cu condiții schimbate.

   Nu stabiliți că un anumit dispozitiv sau driver este cauza doar după numele modulului cu un DPC/ISR lung. Este posibil să vă uitați la o valoare mare dintr-un alt moment sau la o componentă comună prin care trec mai multe dispozitive.

flowchart TB
    accTitle: Cum se investighează așteptarea în intervalul căderii de sunet
    accDescr: Se mărește intervalul din jurul căderii de sunet și se verifică starea firului audio. Dacă este gata de rulare și își așteaptă rândul, se corelează cu DPC-urile și ISR-urile de pe același CPU, iar dacă așteaptă date sau altceva, se urmărește procesarea care a încheiat așteptarea.
    A["Mărirea intervalului din jurul tăierii"] --> B{"Starea firului"}
    B -->|"Își așteaptă rândul"| C["DPC și ISR"]
    B -->|"Așteaptă date"| D["Ce a încheiat așteptarea"]

Figura 12: Nu culegeți doar valorile maxime, ci citiți-le suprapuse peste intervalul în care era nevoie de procesarea audio.

Dacă nu reușiți să identificați cauza, predați investigația mai departe ca nestabilită. Atașați versiunile sistemului de operare, aplicației, dispozitivului și driverului, pașii de reproducere, rezultatele dinainte și de după modificări, momentul apariției, profilul de colectare și dacă au existat avertismente privind pierderi. Partajați fișierul ETL conform regulilor interne și doar cu persoanele care se ocupă de investigație.

Încărcarea anticipată în aplicațiile audio

Dacă vă dezvoltați propria aplicație audio, proiectați-o astfel încât procesarea care umple bufferul următor să se încadreze de fiecare dată în termen. WASAPI oferă o metodă prin care primiți, printr-un eveniment, momentul în care bufferul poate fi procesat. Exclusive-Mode Streams

MMCSS este un mecanism care alocă resurse CPU firelor de execuție ale procesărilor multimedia cu constrângeri de timp. Nu are funcții pentru pregătirea în avans a datelor de pe disc sau pentru eliminarea așteptării după blocări. Chiar și când folosiți alocarea prin MMCSS, aveți nevoie separat de un design pentru pregătirea datelor și reducerea așteptărilor. Multimedia Class Scheduler Service

flowchart TB
    accTitle: Ce acoperă MMCSS
    accDescr: MMCSS alocă resurse CPU firelor procesărilor cu constrângeri de timp, dar pregătirea datelor și reducerea așteptării după blocări se realizează printr-un design separat.
    M["MMCSS: alocă resurse CPU"] -.->|"Necesar separat"| D["Pregătirea datelor și mai puține așteptări"]

Figura 13: Alocarea resurselor CPU și designul care aduce datele la timp sunt sarcini diferite.

Principiul de proiectare este separarea procesării care citește din fișiere sau din rețea de procesarea care predă sunetul. Pregătirile a căror durată este greu de anticipat se fac în avans, iar pentru predare se folosesc buffere alocate dinainte. Pe partea audio, organizați lucrurile astfel încât să nu fie nevoie să așteptați răspunsul UI, blocări lungi sau scrieri sincrone în log.

flowchart TB
    accTitle: Separarea pregătirilor greu de anticipat de furnizarea sunetului
    accDescr: Un design în care citirile și operațiile similare se fac în avans, datele pregătite sunt predate procesării audio printr-un buffer, iar așteptările lungi chiar înainte de termenul-limită se reduc.
    A["Pregătirea datelor în avans"] --> B["Zonă de predare alocată dinainte"]
    B --> C["Procesarea audio predă cât e nevoie"]
    C --> D["Furnizare către ieșirea audio"]

Figura 14: Munca de durată este scoasă din momentul imediat dinaintea predării sunetului.

Dacă partea de pregătire se oprește mult timp, stocul se epuizează chiar și cu această separare. Înregistrați nu doar timpul mediu de procesare, ci și cazurile cu procesări sau așteptări lungi și de câte ori furnizarea nu a reușit, folosind o metodă care nu deranjează procesarea audio. Verificați prin API sau driver dimensiunea bufferului și perioada alese efectiv și nu presupuneți că valoarea specificată a fost adoptată ca atare. Rendering a Stream, Low Latency Audio

Atât exemplele numerice, cât și exemplele de design au rol explicativ; nu sunt valori de setare recomandate pentru anumite dispozitive și nici o garanție că sunetul nu se va tăia în orice mediu.

Efectul priorității în timp real

Nu recomandăm ca regulă generală ca utilizatorii să treacă întregul player pe prioritatea „În timp real”. Există riscul de a împiedica alte procesări importante, iar ridicarea priorității unui fir de execuție obișnuit nu elimină nici DPC/ISR, nici așteptarea după date sau blocări. În dezvoltare, folosiți mecanisme precum MMCSS și un design care nu introduce așteptări lungi în furnizarea sunetului. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Așteptări care rămân și cu prioritate în timp real
    accDescr: Chiar dacă playerul este trecut pe prioritate în timp real, firele obișnuite nu pot trece înaintea DPC-urilor și ISR-urilor de pe același CPU, așteptările după date și blocări rămân și există riscul de a împiedica alte procesări importante.
    A["Player pe prioritate în timp real"] --> B["Nu trece înaintea DPC și ISR"]
    B --> C["Așteptările după date și blocări rămân"]
    C --> D["Risc de a împiedica alte procesări"]

Figura 15: Chiar și cu prioritate ridicată, așteptările care întârzie reumplerea audio rămân.

Articole conexe

• „Planificarea procesorului” din Windows și setarea pentru serviciile de fundal
• Cum izolați în siguranță cauza unui disc la 100% în Windows
• De ce este RDP lent deși conexiunea este rapidă?

Referințe

• Microsoft Learn, Rendering a Stream. Furnizarea datelor în bufferul de redare, cantitatea rămasă, dimensiunea reală a bufferului, definiția cadrului PCM.
• Microsoft Learn, Exclusive-Mode Streams. Momentul furnizării bufferului și glitch-urile audio, echilibrul cu latența, furnizarea pe bază de evenimente. Nu este o recomandare generală a modului exclusiv în sine.
• Microsoft Learn, Low Latency Audio. Traseul audio în Windows, bufferele, dispozitivele, procesarea efectelor și latența, compromisurile latenței scăzute.
• Microsoft Learn, CPU Analysis. CPU-urile logice, stările Ready/Waiting ale firelor de execuție, relația dintre DPC/ISR și execuția firelor, analiza CPU în WPA.
• Microsoft Learn, Introduction to DPCs. Mecanismul care scurtează procesarea întreruperilor și transferă restul muncii către DPC.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. DPC/ISR lungi și frecvente, furnizarea insuficientă de date și glitch-urile audio. Valorile de avertizare ale evaluării nu sunt generalizate ca criterii de siguranță pentru toate dispozitivele.
• Microsoft Support, Fix distorted or crackling audio in Windows. Verificarea îmbunătățirilor audio, a formatului, a driverelor și altele.
• Microsoft Learn, Windows Performance Recorder. Înregistrarea ETW și analiza cu WPA, utilizarea Windows Performance Toolkit.
• Microsoft Learn, Built-in Recording Profiles. More Options în WPR și profilurile standard, precum Audio glitches și CPU usage.
• Microsoft Learn, WPR How-to Topics. Pornirea înregistrării și salvarea cu Save, conflictele cu sesiunile existente, atenția la datele personale și la evenimentele pierdute.
• Microsoft Learn, Multimedia Class Scheduler Service. Alocarea resurselor CPU pentru procesările multimedia cu constrângeri de timp.
• Microsoft Learn, Scheduling Priorities. Prioritățile proceselor și firelor de execuție și precauțiile privind prioritatea în timp real.

Articole conexe

Cele mai recente articole care au aceleași etichete. Aprofundați cunoștințele prin subiecte apropiate.

Subiecte conexe

Pagini de subiect apropiate de această temă. Pornind de la articol, puteți ajunge la servicii conexe și la alte articole.

Servicii legate de această temă

Acest articol se leagă de paginile de servicii de mai jos. Alegeți punctul de intrare cel mai apropiat de nevoia dumneavoastră.

Întrebări frecvente

Întrebările pe care le primim cel mai des în consultanță pe tema acestui articol.

De ce se taie sunetul când utilizarea CPU este de doar aproximativ 10%?

Sunetul are un termen-limită: datele următoare trebuie adăugate înainte să se epuizeze cele care se redau acum. Chiar dacă utilizarea totală a CPU este scăzută, reumplerea poate să nu se încadreze în timp dacă în acel moment procesarea audio nu a putut rula ori era în așteptarea datelor de care avea nevoie. Nu toate căderile de sunet au această cauză, așa că sunt necesare și comparații în care schimbați dispozitivul de ieșire sau aplicația.

Dispar căderile de sunet dacă măresc bufferul audio?

Când reumplerea întârzie temporar, un buffer mai mare poate uneori absorbi întârzierea. Însă crește și timpul de așteptare până la redarea sunetului acumulat. Nu este o setare care să rezolve și o lipsă continuă de capacitate de procesare sau deconectarea dispozitivului. În aplicațiile și driverele în care valoarea poate fi modificată, notați valoarea inițială și comparați schimbând-o câte o treaptă.

Câte milisecunde de sunet înseamnă 480 de cadre la 48 kHz?

480 ÷ 48000 de secunde, adică 10 milisecunde. Un cadru PCM este unitatea care grupează eșantioanele tuturor canalelor pentru același moment. Această valoare este durata sunetului reprezentată de acel număr de cadre, nu latența totală care include dispozitivele și aplicațiile.

Este vinovat de căderile de sunet driverul cu timp lung de execuție DPC sau ISR?

Poate fi un candidat, dar nu se poate stabili doar după clasamentul timpilor de execuție. Corelați intervalul în care s-a produs căderea de sunet cu așteptările firului audio și cu execuția DPC/ISR pe același CPU. Nu concluzionați doar după numele modulului că este vorba de un defect al unui anumit dispozitiv sau driver și verificați și rezultatele obținute cu alte condiții de reproducere.

Se îmbunătățește situația dacă trec playerul pe prioritate în timp real?

Nu recomandăm acest lucru ca regulă generală. Chiar dacă ridicați prioritatea unui fir de execuție obișnuit, acesta tot nu poate trece înaintea DPC-urilor și ISR-urilor obișnuite de pe același CPU, iar așteptările după date sau blocări nu dispar. Dezvoltatorii folosesc mecanisme precum MMCSS și un design care nu introduce așteptări, iar utilizatorii compară mai întâi condițiile de reproducere și traseele de ieșire.

Profilul autorului

Pagina de profil a autorului articolului.

Go Komura

Reprezentant al KomuraSoft LLC

Specializat în dezvoltarea de software Windows, consultanță tehnică și investigarea defectelor, cu puncte forte în proiectele care pornesc de la resurse software existente și în investigarea avariilor ale căror cauze sunt greu de identificat.