Miksi ääni katkeilee, vaikka CPU-käyttöaste on matala? – Tarkastelussa puskurit ja määräajat

Musiikkia kuunnellessa ääni katkeaa välillä lyhyellä ”napsahduksella”. Tehtävienhallinnan mukaan CPU-käyttöaste on noin 10 %, mutta silti juuri ääni ei pysy vakaana. Miksi ääni tällaisessa tilanteessa katkeaa, vaikka CPU:lla on kapasiteettia vapaana?

Vaikka CPU-käyttöaste on matala, ääni voi katketa, jos seuraavan äänidatan täydennys ei ehdi määräaikaan mennessä. Seuraava data on nimittäin luovutettava sillä aikaa, kun puskuriin jäänyttä ääntä vielä toistetaan. Täydennys voi myöhästyä esimerkiksi datan tai lukituksen odottamisen tai tarvittavalla loogisella suorittimella suoritettavien DPC/ISR-rutiinien vuoksi, eikä siihen tarvita koko CPU:n kapasiteetin loppumista. Exclusive-Mode Streams, CPU Analysis

Kuultu ”napsahdus” ei kuitenkaan yksin riitä osoittamaan, että kyse on alivuodosta. Samankaltaisia oireita voivat aiheuttaa myös äänilähde, sovellus, ääniefektit tai toistolaite. Ensin muutetaan samalla äänilähteellä ehtoja yksi kerrallaan, palautetaan ne ennalleen ja verrataan tuloksia; jos syytä ei näin saada rajattua, tallennetaan katkoa edeltävä ja sitä seuraava ajanjakso. Fix distorted or crackling audio in Windows

Tämä artikkeli käsittelee tätä kysymystä sekä siitä seuraavia kysymyksiä: ”Riittääkö, että puskuria suurennetaan?” ja ”Mitä pitää verrata ja mitä tallentaa, jotta syy saadaan rajattua?” Artikkelin tarkoitus ei ole varmistaa yksittäisen vian syytä pelkän CPU-käyttöasteen tai kuullun äänen perusteella.

Kohteena on pääasiassa äänilähtö Windows 11:ssä. Vertailukohteina ovat sisäinen, langallinen, USB- ja Bluetooth-lähtö sekä muut vastaavat. Musiikintuotanto-ohjelmistojen (DAW) osalta käsitellään myös vertailua silloin, kun sovellus tai ohjain tarjoaa puskuriasetuksen. Koko äänitysketjun suunnittelua ja laitekohtaista langattoman yhteyden diagnosointia ei käsitellä kattavasti.

Selityksen perusesimerkkinä on jaettu tila. Todellinen reitti, puskurin koko ja käsittelyjakso vaihtelevat sovelluksen, API:n, ohjaimen ja laitteen mukaan, eikä ole olemassa kaikille sovelluksille yhteistä puskuriasetusnäkymää. Low Latency Audio

Tässä esitetyt CPU-käyttöaste, 10 millisekunnin jäljellä oleva määrä, täydennyksen ajankohdat ja muut vastaavat ovat havainnollistavia oletuksia. Ne eivät ole raportteja tietyllä tietokoneella mitatusta katkon toistumisesta tai parannuksesta. Artikkelin loppuosan toimenpiteet ovat tarkistusvaiheita, jotka lukija tekee omassa ympäristössään.

Toimintaperiaatteen voi lukea järjestyksessä seuraavasta osiosta ”Äänentoistopuskuri” alkaen. Äänikatkojen tutkimiseen tarvittavat toimenpiteet ovat osioissa ”Toistumisehtojen vertailu” ja ”Äänikatkon tallentaminen WPR:llä”.

Kaaviossa yhtenäinen viiva kuvaa suhdetta, joka pätee aina, ja katkoviiva ehdollista suhdetta (ehdot on kuvattu kunkin suhteen kohdalla yksityiskohtasivulla). Suhteiden täydellinen luettelo (yhteensä 5, todisteineen ja varmuustasoineen) sekä keskeisten käsitteiden määritelmät on koottu tietokartan yksityiskohtasivulle (japaniksi). Data: JSON-LD / Turtle

Äänentoistopuskuri

Pelkkä musiikkitiedoston tallentaminen ei saa kaiutinta soimaan. Sovellus valmistelee äänidatan ja toimittaa sen Windowsin ja ohjaimen kautta toistolaitteelle. Äänentoistopuskuri on alue, joka säilyttää tilapäisesti seuraavaksi toistettavan datan. Sillä aikaa kun laite toistaa nykyistä dataa, syöttävä osapuoli valmistelee ja täydentää seuraavan. Rendering a Stream

flowchart TB
    accTitle: Hieman tulevaa ääntä puskuroidaan ennen toistoa
    accDescr: Valmisteltu äänidata täydennetään puskuriin, ja sillä aikaa kun laitteen toisto etenee, valmistellaan seuraava data.
    A["Seuraavan äänen valmistelu"] --> B["Täydennys puskuriin"]
    B --> C["Puskuroidun äänen toisto"]
    C -.->|"Ennen kuin loppuu"| A

Kuva 1: Jotta toisto jatkuisi, täydennyksen on pysyttävä ääntä kuluttavan osapuolen tahdissa.

Kuva 1 on käsitekaavio, joka näyttää vain täydennyksen ja kulutuksen suhteen. Se ei esitä todellisen ääniketjun useita puskureita fyysisesti yhtenä alueena. Low Latency Audio

Puskurin tehtävä on tasoittaa ääntä valmistelevan ja ääntä käyttävän osapuolen välisiä lyhyitä ajoituseroja ja pitää toisto yhtenäisenä. Puskurin kapasiteetti on kuitenkin eri asia kuin se, kuinka paljon toistamatonta dataa siinä juuri nyt on. Se, että ”kapasiteettia on 10 ms”, ei tarkoita, että jäljellä olisi aina 10 ms ääntä. Rendering a Stream

Tässä artikkelissa täydennyksen määräajaksi kutsutaan ajallista rajoitetta, jonka mukaan tarvittavan seuraavan datan on oltava perillä ennen kuin toistettavana oleva data loppuu. Äänenkäsittelyssä vaatimuksena on, että data ”oli valmiina soittoajankohtaan mennessä”. Pelkkä ”laskenta valmistui lopulta” ei riitä. Alivuoto (underrun) on tila, jossa syöttö ei ehdi ajoissa ja toistettava data loppuu; se johtaa äänikatkoihin tai naksahduksiin. Vaikka data saapuisi myöhässä, jo kuultua katkosta ei voi jälkikäteen paikata. Exclusive-Mode Streams

Äänidatan kulkureitti

Tavallisessa jaetussa tilassa Windowsin äänimoottori vastaanottaa toistosovelluksen valmisteleman datan, miksaa useita ääniä tai lisää efektejä ja välittää datan sitten ohjaimelle ja toistolaitteelle. Toistosovellus osallistuu sekä äänilähteen lukemiseen että datan syöttämiseen lähtöön, ja ohjain ja toistolaite kuljettavat datan laitteen puolelle ja toistavat sen. Low Latency Audio

flowchart TB
    accTitle: Äänidatan reitti jaetussa tilassa
    accDescr: Äänimoottori miksaa toistosovelluksen valmisteleman datan ja käsittelee efektit, välittää sen ohjaimelle, ja toistolaite toistaa sen.
    A["Toistosovellus: datan valmistelu"] --> E["Äänimoottori: miksaus, efektit"]
    E --> D["Ohjain: kuljetus laitteelle"]
    D --> O["Toistolaite: toisto"]

Kuva 2: Esimerkki jaetusta tilasta. Välivaiheiden käsittely ja puskurit vaihtelevat API:n ja laitteen mukaan.

Myös laitteen puolella voi olla käsittelyä tai puskureita, joten kokonaisviive ei määräydy pelkästään sovelluksen puskurin perusteella. Tämä selitys olettaa jaetun tilan reitin, eikä se tarkoita, että kaikki API:t kulkisivat saman käsittelyn läpi. Low Latency Audio

Täydennys, kun jäljellä on 10 ms

Oletetaan, että puskurissa on vielä 10 ms toistamatonta dataa. Jos seuraava täydennys tapahtuu 8 ms:n kuluttua, toisto jatkuu katkeamatta, sillä täydennys ehtii ennen kuin jäljellä oleva data loppuu. Jos täydennys onnistuu vasta 12 ms:n kuluttua, data loppuu tässä yksinkertaistetussa esimerkissä 10 ms:n kohdalla.

flowchart TB
    accTitle: Samalla 10 ms:n jäämällä täydennyksen ajankohta ratkaisee
    accDescr: Havainnollistavana oletuksena 10 ms:n jäljellä olevalle toistodatalle 8 ms:n kuluttua tuleva täydennys ehtii ajoissa, mutta 12 ms:n kuluttua tuleva tapahtuu vasta datan loputtua.
    A["10 ms jäljellä"] --> B{"Seuraava täydennys"}
    B -->|"8 ms:n päästä"| C["Jatkuu katkeamatta"]
    B -->|"12 ms:n päästä"| D["Loppuu 10 ms:n kohdalla"]

Kuva 3: Ajallisesti yksinkertaistettu esimerkki. Ratkaisevaa ei ole vain se, onnistuiko täydennys, vaan myös se, milloin.

CPU-käyttöaste ja täydennyksen viive

CPU-käyttöaste kertoo, kuinka kiireinen suoritin oli tietyn ajanjakson aikana. Se mittaa eri asiaa kuin sitä, pääsikö äänenkäsittely suoritukseen juuri sillä hetkellä, kun sitä tarvittiin. Vaikka CPU:lla olisi kapasiteettia vapaana suurimman osan sekunnista, yksikin 12 ms:n jakso, jolloin täydennys ei onnistu, riittää siihen, että tämä yksittäinen viive katkaisee äänen. Myöhemmin vapaana olevalla käsittelykapasiteetilla ei voi saada mennyttä toistoajankohtaa takaisin. CPU Analysis

flowchart TB
    accTitle: Keskimääräinen kapasiteetti ja yksi myöhästynyt täydennys
    accDescr: Vaikka CPU:lla on kapasiteettia vapaana suurimman osan sekunnista, yksikin 12 ms:n jakso ilman täydennystä voi katkaista äänen tällä yksittäisellä viiveellä.
    A["CPU:ta vapaana suurimman osan sekunnista"] --> B["Kerran 12 ms ilman täydennystä"]
    B --> C["Tämä yksi kerta katkaisee äänen"]

Kuva 4: Keskimääräinen vapaa kapasiteetti ei tuo mennyttä toistoajankohtaa takaisin.

Määräajasta ei kuluta vain laskenta-aika. Siihen kuuluvat myös odotus ennen käsittelyn alkamista ja odotus siihen asti, että tarvittava data saapuu. Siksi myös tutkimuksen kysymys muutetaan: ei pelkästään ”kuinka monta prosenttia CPU:n käyttöaste oli”, vaan ”mitä seuraava ääni odotti sillä hetkellä, kun ääni katkesi”.

Datan ja lukituksen odotus

Oletetaan, että äänidataa valmisteleva käsittely odottaa tiedoston lukemisen valmistumista. Sama pätee, jos se odottaa lukitusta, jota jokin toinen sovelluksen sisäinen käsittely pitää hallussaan. Odottava käsittely itse käyttää vain vähän CPU:ta, mutta laitteen puolella toisto jatkuu ja jäljellä oleva ääni vähenee. Results for the Streaming Media Performance Assessment, CPU Analysis

flowchart TB
    accTitle: Toisto etenee myös odotuksen aikana, joka ei käytä CPU:ta
    accDescr: Kun äänenkäsittely odottaa dataa tai lukitusta, kyseinen käsittely ei käytä CPU:ta, mutta toisto etenee ja jäljellä oleva määrä vähenee, ja jos täydennys myöhästyy, puskuri voi tyhjentyä.
    A["Äänenkäsittely odottaa dataa"] --> B["Se ei käytä CPU:ta"]
    B --> C["Toisto etenee silti"]
    C --> D["Myöhäinen täydennys tyhjentää varaston"]

Kuva 5: Se, ettei CPU:ta käytetä, on eri asia kuin se, että tarvittava työ on tehty.

DPC, ISR ja äänisäie

ISR on rutiini, joka käsittelee laitteilta tulevia keskeytyksiä. DPC on mekanismi, joka siirtää jäljellä olevan työn myöhemmäksi, jotta keskeytyskäsittely pysyisi lyhyenä. Tavalliset DPC:t suoritetaan samalla loogisella suorittimella ennen tavallisia säikeitä, ja niin kauan kuin tavallinen DPC tai ISR on käynnissä, kyseisellä loogisella suorittimella ei voi suorittaa tavallisia säikeitä. Introduction to DPCs, CPU Analysis

Vaikka koko CPU:lla olisi kapasiteettia vapaana, syöttö voi myöhästyä, jos nämä venyvät tai toistuvat usein äänenkäsittelyn tarvitsemalla suorittimella. Microsoftin äänen ja videon suorituskykyanalyysia käsittelevässä aineistossa myös verkko-, tallennus- ja grafiikkaohjainten sekä muiden ohjainten pitkät DPC/ISR-rutiinit mainitaan äänikatkojen mahdollisina syinä. Ei ole sanottua, että riittää tutkia pelkästään ääntä tuottavaa laitetta. Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: Kun laitteiden palveleminen viivästyttää äänen suoritusta
    accDescr: Jos tavallinen DPC tai ISR venyy äänenkäsittelyn tarvitsemalla suorittimella, säikeen suoritus viivästyy, mikä voi vaikuttaa täydennyksen määräaikaan.
    A["DPC, ISR samalla CPU:lla"] -->|"Jos venyy"| B["Äänen suoritus joutuu odottamaan"]
    B --> C["Seuraava täydennys myöhästyy"]
    C --> D["Jäämän loputtua ääni katkeaa"]

Kuva 6: Myös muun kuin ääntä tuottavan laitteen käsittely voi välillisesti vaikuttaa äänen täydennykseen.

Yhteistä rajaa, kuten ”jos DPC kestää enintään näin monta mikrosekuntia, äänikatkoja ei tule millään tietokoneella”, ei voi vetää. Suorituskyvyn arviointiaineiston varoitusarvot koskevat kyseisen arvioinnin ehtoja, eikä niitä käytetä turvallisuusrajana irrallaan todellisesta täydennyksen määräajasta ja puskurin pelivarasta. Results for the Streaming Media Performance Assessment

Puskurin koko ja toistoviive

Jos samoilla ehdoilla etukäteen puskuroidaan enemmän ääntä, tilapäiset täydennysviiveet on helpompi niellä, mutta uusi tuotettu ääni joutuu odottamaan jo puskuroidun äänen perässä. Pelkässä musiikin kuuntelussa hyväksyttävä odotus muuttuu häiritseväksi, kun soitetaan koskettimia tai kun omaa mikrofoniin puhuttua ja käsiteltyä ääntä kuunnellaan itse: toiminnon ja äänen välinen viive alkaa tuntua. Exclusive-Mode Streams, Low Latency Audio

flowchart TB
    accTitle: Puskurin pelivara ja reagoinnin viive
    accDescr: Kun etukäteen puskuroitavan äänen määrää lisätään, tilapäiset täydennysviiveet on helpompi niellä, mutta myös odotus ennen uuden äänen toistoa kasvaa.
    A["Enemmän ääntä puskuriin etukäteen"] --> B["Täydennysviiveet helpompi niellä"]
    B -->|"Vastineeksi"| C["Uusi ääni odottaa jonon perällä"]
    C --> D["Ääni viivästyy toiminnosta"]

Kuva 7: Puskurin kasvattaminen on säätö, joka luo pelivaraa reagointinopeuden kustannuksella.

Ei pidä paikkaansa, että ”mitä pienempi, sitä parempi suorituskyky”, eikä myöskään, että ”mitä suurempi, sitä oikeampi”. Tavoitteena on säilyttää tarvittava reagointinopeus ja samalla varata riittävästi pelivaraa, jotta ääni ei katkea.

Puskurin kasvattaminen luo pelivaraa tilapäisiä syöttöviiveitä varten. Jos jo keskimääräinen syöttö ei pysy kulutuksen tahdissa, äärellisen puskurin kasvattaminen vain pidentää aikaa siihen, kun se tyhjenee, eikä se poista laitteen yhteyden katkeamista. Tämä ei myöskään ole suositus siitä, että yksinomaisen tilan käyttö ratkaisisi kaiken. Exclusive-Mode Streams

480 kehystä 48 kHz:llä

PCM-kehys on yksikkö, joka kokoaa kaikkien kanavien samana ajanhetkenä toistettavat näytteet. Stereon vuoksi kehysmäärää ei kaksinkertaisteta aikaa laskettaessa. Kehysmäärän edustaman äänen pituus saadaan kaavalla ”kehysmäärä ÷ näytteenottotaajuus”: 48 kHz:llä 480 kehystä on 480 ÷ 48000 sekuntia eli 10 ms. Jos kehysmäärää kasvatetaan 48 kHz:llä, puskuroitavan äänen kesto myös pitenee. Rendering a Stream

Tämä aika ei ole sama kuin kokonaisviive koskettimen painamisesta siihen, kun ääni kuuluu. Siihen lisätään myös sovelluksen, ohjaimen, laitteen sekä muiden puskureiden ja käsittelyjen aika. Myös DAW:n asetusarvot luetaan vasta, kun yksikkö ja kohteena oleva puskuri on tarkistettu. Low Latency Audio

flowchart TB
    accTitle: Kehysmäärästä laskettu aika ja kokonaisviive
    accDescr: Kun 480 kehystä jaetaan 48000:lla, saatava 10 ms on puskurin edustama aika; kun siihen lisätään sovelluksen, ohjaimen, laitteen ja muiden käsittelyjen aika, saadaan kokonaisviive koskettimesta ääneen.
    A["480 ÷ 48000"] --> B["Puskurin edustamat 10 ms"]
    B -->|"Muu käsittely lisätään"| C["Kokonaisviive koskettimesta ääneen"]

Kuva 8: Kehysmäärästä laskettu aika on vain osa kokonaisviivettä.

Toistumisehtojen vertailu

Ensin rajataan yhdistelmä, jossa katko toistuu, ja yksityiskohtaiseen tallennukseen siirrytään vain tarvittaessa. Seuraavat vaiheet on tarkoitettu syyn selvittämiseen; ne eivät ole toimenpidelista, jonka kaikki asetusmuutokset tehtäisiin kerralla.

Tallenna työsi ja lopeta varsinaiset kokoukset ja äänitykset ennen kokeilua, ja käytä korville turvallista äänenvoimakkuutta. Kirjaa muistiin alkuperäinen lähtö, äänitehosteiden tila, puskuriarvot ja muut vastaavat, jotta voit palauttaa ne. Ohita kohdat, joille ei ole asetusta, äläkä muuta rekisteriä tai muuta vastaavaa vain saadaksesi asetuksen näkyviin.

1. Valitse lyhyt äänilähde ja havainnointiaika, joita käytät koko ajan samoina, ja tarkista, toistuuko katko alkuperäisillä ehdoilla.

   Kirjaa muistiin Windowsin versio, sovelluksen nimi ja versio, toistolaite, liitäntätapa ja ohjaimen versio. Kirjaa myös äänikatkojen ajankohdat, silloin tehdyt toiminnot ja katkojen määrä. Jos katko ei toistu alkuperäisillä ehdoilla, älä tulkitse sitä parannukseksi, vaan palaa selvittämään, millä ehdoilla katko toistuu.

2. Valitse alla olevasta taulukosta yksi vertailu ja soita ääni muuttaen vain sitä ehtoa.

   Verrattava ehto	Mitä selvitetään
   Paikallisesti tallennettu äänilähde ja toisto verkon kautta	Esiintyykö katko vain verkon kautta toistettaessa. Jos sisältö on sama mutta muoto tai käsittelyreitti eroaa, kirjaa myös se.
   Sama äänilähde toisessa sovelluksessa	Painottuuko katko tiettyyn sovellukseen.
   Bluetooth- tai vastaava lähtö ja sisäinen tai langallinen lähtö	Painottuuko katko tiettyyn lähtöreittiin.
   Äänitehosteet käytössä ja pois käytöstä	Muuttuuko tilanne yhdessä efektikäsittelyn kanssa.
   DAW:n tai vastaavan nykyinen puskuri ja yhtä porrasta suurempi arvo	Muuttuuko tilanne, kun etukäteen puskuroitavaa pelivaraa lisätään. Onko myös toiminnon ja äänen välinen viive hyväksyttävä.

3. Jos vertaat äänitehosteita, poista asetus tilapäisesti käytöstä kyseisestä lähdöstä.

   Valitse Windowsin kohdassa ”Asetukset” → ”Järjestelmä” → ”Ääni” kyseinen lähtö ja poista ”Äänitehosteet” käytöstä, jos se on ympäristössäsi saatavilla. Jos näkymä poikkeaa tai jokin kohta puuttuu, tarkista kyseisen version tai laitteen ohjeet. Fix distorted or crackling audio in Windows

4. Palauta muuttamasi asetus ennalleen ja kokeile uudelleen samalla äänilähteellä ja havainnointiajalla.

   Aseta rinnakkain tulokset ehdoista ”alkuperäinen”, ”yksi ehto muutettu” ja ”palautettu ennalleen”. Palauta tehoton muutos alkuperäiseen tilaan ennen kuin siirryt seuraavaan vertailuun. Jos asetusten yhdistelmää muutetaan jatkuvasti, on mahdotonta tietää, mikä auttoi.

5. Jos kokeilet ohjaimen vaihtamista, tarkista ensin virallinen jakelukanava ja palautustapa.

   Käytä Windows Updatea tai laitevalmistajan virallista jakelua ja kirjaa muistiin versiot ja asetukset ennen muutosta ja sen jälkeen. Varmista etukäteen, että voit palata alkuperäiseen, ja jos tietokone on organisaation hallinnoima, keskustele ylläpitäjän kanssa. Älä pidä ongelmaa ratkaistuna vain siksi, että ääni toistui kerran heti päivityksen jälkeen, vaan tarkista samoilla toistumisehdoilla. Fix distorted or crackling audio in Windows

Tavoitteena on muistiinpano, joka yhdistää oireen ja ehdot, esimerkiksi: ”katko toistuu tällä sovelluksella, kun käytetään tätä lähtöä”. Vaikka löytäisit asetuksen, joka parantaa tilannetta, pidä se erillään syyn varmistamisesta.

flowchart TB
    accTitle: Vertailu muuttamalla yhtä ehtoa ja palauttamalla se
    accDescr: Samalla äänilähteellä tarkistetaan katkon toistuminen, muutetaan yksi ehto, kuten sovellus tai lähtö, ja kirjataan myös tulos palautuksen jälkeen.
    A["Toisto alkuperäisellä yhdistelmällä"] --> B["Toisto yksi ehto muutettuna"]
    B --> C["Toisto palautuksen jälkeen"]
    C --> D["Katkon ehdot ja ajankohta muistiin"]

Kuva 9: Kerran parantunutta tilannetta tärkeämpää on varmistaa, että ehdot ja oireet vastaavat toisiaan toistuvasti.

Toistettavuus ennen muutosta ja sen jälkeen

”Oire saatiin hillittyä”, ”ehdot saatiin rajattua” ja ”perimmäinen syy saatiin tunnistettua” ovat eri saavutuksia. Kirjaa johtopäätös sen mukaan, mihin asti havainnot ulottuvat.

flowchart TB
    accTitle: Kolme tulosta, jotka viittaavat yhteyteen ehdon kanssa
    accDescr: Jos katko toistuu alkuperäisillä ehdoilla, paranee yhtä ehtoa muuttamalla ja toistuu taas palautettaessa, se on vihje yhteydestä kyseiseen ehtoon, mutta se pidetään erillään syyn varmistamisesta.
    A["Toistuu alkuperäisillä ehdoilla"] --> B["Paranee yhdellä muutoksella"]
    B --> C["Toistuu taas palautettaessa"]
    C --> D["Vihje yhteydestä ehtoon"]

Kuva 10: Vaikka kaikki kolme täyttyvät, tuloksena on vasta vihje yhteydestä.

Matala CPU-käyttöaste ei todista, että äänen määräajassa pysyttiin. Toisaalta pelkästään äänikatkon esiintymisen perusteella ei voi myöskään sanoa, että myöhästynyt täydennys olisi ollut perimmäinen syy. Vertaa äänilähdettä, sovelluksen käsittelyä, efektejä, lähtöreittiä ja muita tekijöitä ja tee arvio havaitun rajoissa. Fix distorted or crackling audio in Windows

Kun otat käyttöön väliaikaisen kiertotien, kirjaa muistiin alkuperäinen asetus, muutoksen sisältö, havainnointiaika, toistuiko katko uudelleen sekä hyväksyttävä viive. Jos perimmäinen syy on vielä vahvistamatta, kirjaa myös se.

Äänikatkon tallentaminen WPR:llä

Tämä tehdään, jos syytä ei saada rajattua pelkällä ehtojen vertailulla tai jos halutaan tutkia ohjaimen puolen käsittelyä. WPR on tallennukseen ja WPA tallennetun aikajanan analysointiin käytettävä työkalu. Valmistele Windows Performance Toolkit, tallennukseen tarvittavat oikeudet ja ETL-tiedoston tallennuspaikka. Jos työkalut asennetaan ja tallennus tehdään hallinnoidulla tietokoneella, pyydä apua ylläpitäjältä. Tarkista näyttönimet ja käytettävissä olevat profiilit asentamastasi versiosta. Windows Performance Recorder

ETL-tiedosto voi sisältää prosessien nimiä, tiedostopolkuja ja muita vastaavia tietoja. Tarkista ennen tallennusta organisaatiosi säännöt ja se, kenen kanssa tiedosto jaetaan, äläkä liitä sitä sellaisenaan julkiseen paikkaan. Jos toinen tallennusistunto on jo käynnissä, älä pysäytä sitä omin päin, vaan varmista asia vastuuhenkilöltä. WPR How-to Topics

1. Avaa WPR:n ”More Options” ja valitse tarkoitukseen sopiva tallennusprofiili.

   Vakioprofiileihin kuuluvat ”Audio glitches” ja ”CPU usage”. Valitse asetus, jolla voit tutkia sekä äänen katkonaisuutta että CPU:n toimintaa. Tarkista käytettävissä olevat profiilit, näyttönimet ja kerättävät tiedot asentamastasi versiosta, äläkä valitse asetusta, joka tallentaa kaikkia tyyppejä pitkään. Built-in Recording Profiles

2. Aloita tallennus ennen kuin saat katkon toistumaan.

   Jos näkyviin tulee vahvistus olemassa olevan tallennuksen pysäyttämisestä, älä jatka, vaan peru aloitus ja varmista asia vastuuhenkilöltä. Pidä ehdot samoina kuin ilman tallennusta ja ota huomioon, että tallennuksen oma kuormitus voi muuttaa oiretta. WPR How-to Topics

3. Soita ääni vertailussa löytyneillä ehdoilla ja kirjaa muistiin katkon ajankohta ja silloin tehty toiminto.

   Ota mukaan myös hieman ongelmatonta jaksoa ennen oiretta ja sen jälkeen. Jos katko ei toistunut tallennuksen aikana, merkitse se selvästi, äläkä käsittele tallennetta sellaisena, joka olisi tavoittanut syyn.

4. Kun katko on toistunut, lopeta tallennus ”Save”-painikkeella ja tallenna ETL-tiedosto.

   ”Cancel” ei tallenna mitään. Kirjaa muistiin tallennuspaikka, toistumisehdot, tehtiinkö tallennus sekä se, tuliko varoitus kadonneista tapahtumista. Jos tapahtumia on kadonnut, älä tulkitse tallenteen näkymättömiä jaksoja normaaleiksi. WPR How-to Topics

Kun sinulla on ETL-tiedosto sekä muistiinpanot katkon ajankohdasta, toiminnosta ja ehdoista, olet valmis vertailemaan niitä WPA:ssa. Se, että tallenne on tallennettu, ei vielä takaa, että tarvittavat tapahtumat saatiin talteen. Tarkista sisältö seuraavan osion ”Suoritus ja odotus katkon ympärillä” mukaan.

flowchart TB
    accTitle: Lyhyt tallenne, joka sisältää katkon
    accDescr: Tallennus aloitetaan WPR:llä, oire saadaan toistumaan ja sen ajankohta kirjataan, ja pysäytetty ja tallennettu tallenne tutkitaan WPA:ssa.
    A["Tallennus käyntiin WPR:llä"] --> B["Katko toistumaan samoilla ehdoilla"]
    B --> C["Aika ja toiminto muistiin, tallennus"]
    C --> D["Ympäröivä jakso suurennetaan WPA:ssa"]

Kuva 11: Oireen jälkeen katsottu CPU-käyttöaste ei riitä, vaan tarvitaan tallenne siltä jaksolta, jolloin oire ilmeni.

Suoritus ja odotus katkon ympärillä

Valmistele tallennettu ETL-tiedosto ja muistiinpano katkon toistumisajankohdasta. Seuraavat vaiheet ovat lähtökohta WPA:lla tehtävälle tutkimukselle. Jos tarvitaan pinoja ja symboleita sisältävää yksityiskohtaista analyysia, pyydä apua ylläpitäjältä tai kehittäjiltä ja huolehdi tallenteen asianmukaisesta käsittelystä.

1. Avaa ETL-tiedosto WPA:ssa ja suurenna katkoa edeltävä ja seuraava jakso tallentuneiden äänitapahtumien ja katkon ajankohdan perusteella.

   Jätä vertailua varten näkyviin myös jakso, jolla oiretta ei ole. Älä katso pelkkää enimmäisarvojen järjestystä, vaan vertaa samaan aikaväliin rajattuna.

2. Tarkista samalta väliltä ”DPC/ISR” ja ”CPU Usage (Precise)”.

   Jos tarvittavaa dataa ei ole, tarkista, kerääkö profiili sitä, ja palaa WPR-tallennukseen. Se, ettei jostakin ole tallennetta, on eri asia kuin se, ettei ongelmaa ollut. CPU Analysis, Built-in Recording Profiles

3. Erottele, odottiko ääneen liittyvä säie vuoroaan suoritusvalmiina vai odottiko se dataa tai muuta.

   Ensimmäisessä tapauksessa tarkista, onko asianomaisella loogisella suorittimella ollut pitkään käynnissä DPC/ISR-rutiineja tai vastaavia. Jälkimmäisessä tapauksessa selvitä tallentuneiden tapahtumien ja pinojen avulla, mikä vapautti odotuksen. Koska keskeytys voi keskeyttää myös suorituksessa olevan säikeen, älä rajaa tarkastelua pelkkään Ready-aikaan, vaan aseta päällekkäin myös DPC/ISR-jaksot. CPU Analysis

4. Kirjaa yhdessä ajallinen vastaavuus katkon kanssa, asianomainen suoritin ja ehtojen muuttamisen tulokset.

   Älä totea tiettyä laitetta tai ohjainta varmaksi syyksi pelkän pitkän DPC/ISR-rutiinin moduulinimen perusteella. Saatat katsoa toisen ajankohdan suurta arvoa tai osaa, jonka kautta useat laitteet kulkevat.

flowchart TB
    accTitle: Odotuksen laadun tutkiminen katkon jaksolla
    accDescr: Katkoa edeltävä ja seuraava jakso suurennetaan ja äänisäikeen tila tarkistetaan. Jos säie odotti vuoroaan suoritusvalmiina, sitä verrataan saman suorittimen DPC- ja ISR-rutiineihin; jos se odotti dataa tai muuta, selvitetään, mikä käsittely vapautti odotuksen.
    A["Katkon ympäristön suurennus"] --> B{"Säikeen tila"}
    B -->|"Odottaa vuoroaan"| C["DPC, ISR"]
    B -->|"Odottaa dataa"| D["Odotuksen vapauttanut käsittely"]

Kuva 12: Älä poimi pelkkiä enimmäisarvoja, vaan lue ne päällekkäin sen jakson kanssa, jolla äänenkäsittelyä tarvittiin.

Jos syytä ei saada tunnistettua, siirrä tutkimus eteenpäin vahvistamattomana. Liitä mukaan käyttöjärjestelmän, sovelluksen, laitteen ja ohjaimen versiot, vaiheet, joilla katko saadaan toistumaan, tulokset ennen muutosta ja sen jälkeen, katkon ajankohta, keräysprofiili sekä tieto siitä, tuliko varoitus kadonneista tapahtumista. Jaa ETL-tiedosto organisaation sääntöjen mukaisesti vain tutkimuksesta vastaavalle osapuolelle.

Ennakkoluku äänisovelluksissa

Jos teet oman äänisovelluksen, suunnittele se niin, että seuraavan puskurin täyttävä käsittely ehtii joka kerta määräaikaan. WASAPI tarjoaa tavan saada tapahtumana tieto siitä, milloin puskuria voi käsitellä. Exclusive-Mode Streams

MMCSS on mekanismi, joka jakaa CPU-resursseja aikarajoitettua multimediakäsittelyä tekeville säikeille. Sillä ei ole toimintoa, joka lukisi datan levyltä etukäteen tai poistaisi lukitusten odottamisen. Vaikka käyttäisit MMCSS:n resurssienjakoa, datan valmisteluun ja odotusten vähentämiseen tarvitaan erillinen suunnittelu. Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSS:n vastuualue
    accDescr: MMCSS jakaa CPU-resursseja aikarajoitetun käsittelyn säikeille, mutta datan valmistelu ja lukitusodotusten vähentäminen hoidetaan erillisellä suunnittelulla.
    M["MMCSS: CPU-resurssien jako"] -.->|"Tarvitaan erikseen"| D["Datan valmistelu, vähemmän odotusta"]

Kuva 13: CPU-resurssien jakaminen ja suunnittelu, jolla data saadaan ajoissa valmiiksi, ovat eri tehtäviä.

Suunnittelun periaate on erottaa tiedostosta tai verkosta lukeva käsittely ääntä luovuttavasta käsittelystä. Valmistelu, jonka kestoa on vaikea ennakoida, tehdään etukäteen, ja luovutukseen käytetään ennalta varattua puskuria. Äänen puoli rakennetaan niin, ettei sen tarvitse odottaa käyttöliittymän vastausta, pitkiä lukituksia tai synkronisia lokikirjoituksia.

flowchart TB
    accTitle: Vaikeasti ennakoitavan valmistelun ja äänen syötön erottaminen
    accDescr: Rakenne, jossa lukeminen ja vastaavat tehdään etukäteen ja valmisteltu data luovutetaan puskurin kautta äänenkäsittelylle, jotta pitkiä odotuksia juuri ennen määräaikaa on vähemmän.
    A["Datan valmistelu etukäteen"] --> B["Ennalta varattu luovutusalue"]
    B --> C["Äänenkäsittely luovuttaa tarvittavan osan"]
    C --> D["Syöttö äänen lähtöön"]

Kuva 14: Aikaa vievä työ siirretään pois äänen luovutusta välittömästi edeltävästä vaiheesta.

Jos valmisteleva osapuoli pysähtyy pitkäksi aikaa, varasto loppuu tästä erottelusta huolimatta. Kirjaa keskimääräisen käsittelyajan lisäksi myös ne kerrat, joina esiintyi pitkää käsittelyä tai odotusta, sekä se, kuinka monta kertaa syöttö epäonnistui, ja tee se tavalla, joka ei häiritse äänenkäsittelyä. Tarkista todellisuudessa valittu puskurin koko ja jakso API:lta tai ohjaimelta, äläkä oleta, että määritetty arvo otettiin käyttöön sellaisenaan. Rendering a Stream, Low Latency Audio

Sekä lukuesimerkit että suunnitteluesimerkit ovat havainnollistavia; ne eivät ole tietylle laitteelle suositeltuja asetusarvoja eivätkä takuu siitä, ettei ääni katkea missä tahansa ympäristössä.

Reaaliaikaisen prioriteetin vaikutus

Emme suosittele yleisesti, että käyttäjä asettaa koko soitinohjelman prioriteetiksi ”Reaaliaikainen”. Siinä on vaara, että se haittaa muita tärkeitä käsittelyjä, eikä tavallisen säikeen prioriteetin nostaminen poista DPC/ISR-rutiinien aiheuttamia odotuksia tai datan ja lukitusten odotuksia. Kehityksessä käytetään MMCSS:n kaltaisia mekanismeja ja suunnittelua, joka ei tuo pitkiä odotuksia äänen syöttöön. Scheduling Priorities, CPU Analysis

flowchart TB
    accTitle: Odotukset, jotka jäävät reaaliaikaisesta prioriteetista huolimatta
    accDescr: Vaikka soitin asetetaan reaaliaikaiseen prioriteettiin, tavalliset säikeet eivät ohita saman suorittimen DPC- ja ISR-rutiineja, datan ja lukitusten odotukset jäävät, ja on myös vaara, että muut tärkeät käsittelyt häiriintyvät.
    A["Soitin reaaliaikaiseen prioriteettiin"] --> B["DPC:tä ja ISR:ää ei ohiteta"]
    B --> C["Datan ja lukituksen odotus jää"]
    C --> D["Vaara muun käsittelyn häiriintymisestä"]

Kuva 15: Prioriteetin nostamisen jälkeenkin äänen täydennystä viivästyttävät odotukset jäävät.

Aiheeseen liittyviä artikkeleita

• Windowsin ”Suorittimen ajoitus” ja taustapalvelujen asetus
• Windowsin 100 %:n levynkäytön turvallinen vianrajaus
• Miksi RDP on hidas, vaikka yhteys on nopea?

Lähteet

• Microsoft Learn, Rendering a Stream. Toistopuskurin syöttö, jäljellä oleva määrä, todellinen puskurin koko ja PCM-kehyksen määritelmä.
• Microsoft Learn, Exclusive-Mode Streams. Puskurin syötön ajoitus ja äänihäiriöt, tasapainottaminen viiveen kanssa sekä tapahtumaohjattu syöttö. Lähde ei tarkoita, että yksinomaista tilaa sinänsä suositeltaisiin yleisesti.
• Microsoft Learn, Low Latency Audio. Windowsin ääniketju, puskurit, laitteet ja efektikäsittely suhteessa viiveeseen sekä matalan viiveen kompromissit.
• Microsoft Learn, CPU Analysis. Loogiset suorittimet, säikeiden Ready/Waiting-tilat, DPC/ISR-rutiinien ja säikeiden suorituksen suhde sekä CPU-analyysi WPA:ssa.
• Microsoft Learn, Introduction to DPCs. Mekanismi, joka pitää keskeytyskäsittelyn lyhyenä ja siirtää jäljellä olevan työn DPC:lle.
• Microsoft Learn, Results for the Streaming Media Performance Assessment. Pitkät ja toistuvat DPC/ISR-rutiinit, riittämätön datan syöttö ja äänihäiriöt. Arvioinnin varoitusarvoja ei yleistetä kaikkien laitteiden turvallisuusrajoiksi.
• Microsoft Support, Fix distorted or crackling audio in Windows. Äänitehosteiden, ääniformaatin, ohjainten ja muiden tekijöiden tarkistaminen.
• Microsoft Learn, Windows Performance Recorder. ETW-tallennus ja analyysi WPA:lla sekä Windows Performance Toolkitin käyttö.
• Microsoft Learn, Built-in Recording Profiles. WPR:n More Options ja vakioprofiilit, kuten Audio glitches ja CPU usage.
• Microsoft Learn, WPR How-to Topics. Tallennuksen aloittaminen ja tallentaminen Save-painikkeella, ristiriidat olemassa olevien istuntojen kanssa sekä henkilötietoihin ja kadonneisiin tapahtumiin liittyvät varoitukset.
• Microsoft Learn, Multimedia Class Scheduler Service. CPU-resurssien jakaminen aikarajoitetulle multimediakäsittelylle.
• Microsoft Learn, Scheduling Priorities. Prosessien ja säikeiden prioriteetit sekä reaaliaikaiseen prioriteettiin liittyvät varoitukset.

Aiheeseen liittyvät artikkelit

Uusimmat artikkelit, joilla on samoja tunnisteita. Niiden avulla aihetta voi syventää läheisten teemojen kautta.

Aiheeseen liittyvät aihesivut

Tähän teemaan läheisesti liittyviä aihesivuja. Artikkelista voi siirtyä aiheeseen liittyviin palveluihin ja muihin artikkeleihin.

Palvelut, joihin tämä aihe liittyy

Tämä artikkeli liittyy seuraaviin palvelusivuihin. Voitte tutustua lähimpään niistä.

Usein kysytyt kysymykset

Tämän artikkelin aiheesta konsultoinnin yhteydessä usein esitettyjä kysymyksiä.

Miksi ääni katkeaa, vaikka CPU-käyttöaste on vain noin 10 %?

Äänellä on määräaika: seuraava data on täydennettävä ennen kuin parhaillaan toistettava data loppuu. Vaikka koko CPU:n käyttöaste olisi matala, täydennys voi myöhästyä, jos äänenkäsittely ei sillä hetkellä päässyt suoritukseen tai odotti tarvitsemaansa dataa. Kaikki äänikatkot eivät johdu tästä, joten tarvitaan myös vertailu, jossa vaihdetaan toistolaitetta tai sovellusta.

Korjaantuvatko äänikatkot, jos äänipuskuria suurennetaan?

Jos täydennys myöhästyy vain tilapäisesti, suurempi puskuri voi niellä viiveen. Samalla kuitenkin kasvaa myös odotus ennen kuin puskuroitu ääni toistetaan. Asetus ei poista jatkuvaa käsittelykapasiteetin puutetta eikä laitteen yhteyden katkeamista. Jos sovelluksessa tai ohjaimessa arvoa voi muuttaa, kirjaa alkuperäinen arvo muistiin ja vertaa porras kerrallaan.

Kuinka monta millisekuntia ääntä 480 kehystä on 48 kHz:llä?

480 ÷ 48000 sekuntia eli 10 millisekuntia. Yksi PCM-kehys on yksikkö, joka kokoaa saman ajanhetken kaikkien kanavien näytteet. Arvo on kyseisen kehysmäärän edustaman äänen pituus, ei laitteet ja sovellukset sisältävä kokonaisviive.

Onko ohjain, jonka DPC- tai ISR-suoritusaika on pitkä, äänikatkojen syyllinen?

Se voi olla ehdokas, mutta pelkän suoritusaikojen järjestyksen perusteella syytä ei voi varmistaa. Vertaa katkon ajanjaksoa, äänisäikeen odotusta ja samalla suorittimella suoritettuja DPC/ISR-rutiineja. Älä päättele pelkän moduulin nimen perusteella, että tietty laite tai ohjain on viallinen, vaan tarkista myös tulokset, kun toistumisehtoja muutettiin.

Auttaako, jos soittimen prioriteetiksi asetetaan reaaliaikainen?

Emme suosittele sitä yleisesti. Vaikka tavallisen säikeen prioriteettia nostetaan, se ei silti ohita samalla suorittimella suoritettavia tavallisia DPC- ja ISR-rutiineja, eivätkä datan tai lukituksen odotukset katoa. Kehittäjät käyttävät MMCSS:n kaltaisia mekanismeja ja suunnittelua, joka ei tuo odotuksia mukaan, ja käyttäjät vertaavat ensin toistumisehtoja ja äänen lähtöreittiä.

Kirjoittajan profiili

Artikkelin kirjoittajan profiilisivu.

Go Komura

KomuraSoft LLC:n edustaja

Keskittyy Windows-ohjelmistokehitykseen, tekniseen konsultointiin ja vianetsintään. Erityisosaamista ovat hankkeet, joissa on olemassa olevia ratkaisuja, sekä vikojen tutkiminen silloin, kun syy ei ole helposti havaittavissa.