Mga Setting ng Latency ng WASAPI sa Windows: Kumpletong Gabay

Kung gumagamit ka ng audio sa Windows, malao't madali ay makakaranas ka ng WASAPI latency at ang walang katapusang paghahambing sa ASIO at WASAPI . Alam ng sinumang nagre-record sa isang DAW, nag-i-stream ng live, naglalaro ng mga online game, o gumagawa ng musika na ang ilang millisecond na pagkaantala ay maaaring makasira sa isang take, makasira sa isang boses, o maging isang pagsubok ang isang laro.

Sa mga bersyon ng Windows 10 at mga mas bagong bersyon, lubos na pinagbuti ng Microsoft ang audio stack nito, at ngayon ay posible nang makamit ang mas mababang latency gamit ang WASAPI sa shared o exclusive mode , nang hindi isinasakripisyo ang audio ng browser o audio mula sa ibang mga application. Ang susi ay ang pag-unawa kung paano gumagana ang stack, kung ano ang nagbago, kung anong mga limitasyon sa hardware ang ipinapataw nito, at kung anong mga parameter ang maaari nating isaayos (bilang mga user o developer) upang mabawasan ang mga karagdagang millisecond na iyon.

Ano ang audio latency at bakit ito napakahalaga?

Kapag pinag-uusapan natin ang audio latency, tinutukoy natin ang oras na lumilipas mula nang mabuo ang isang tunog hanggang sa marinig mo ito o matanggap ito ng iyong application . Ang oras na ito ay sinusukat sa milliseconds, at habang maaaring mukhang halos bale-wala ito sa papel, sa pagsasagawa, ito ang gumagawa ng pagkakaiba sa pagitan ng isang maayos na karanasan at isang bagay na ganap na hindi komportable.

Sa produksyon at pagre-record ng musika , kailangang marinig ng isang instrumentalista ang kanilang mga sarili halos agad habang tumutugtog . Kung ang bawat nota ay aabutin ng sampu-sampung milliseconds bago bumalik sa pamamagitan ng headphones, magsisimulang magpumilit ang utak sa kung ano ang naririnig at nararamdaman nito, at ang pagpapanatili ng ritmo ay nagiging isang pagsubok.

Sa streaming , mga podcast, at mga video call, ang latency ay maaaring magdulot ng hindi pagkakatugma sa pagitan ng video at audio, nakakainis na mga echo, at ang pakiramdam na parang "nakikipag-usap ka sa pader ." Ang pagkaantala ng sarili mong boses nang ilang millisecond sa headphones ay nagpapabigat sa speaker, nagiging sanhi ng pagkatisod, at hindi natural na tunog sa nakikinig.

Para sa mga manlalaro, lalo na sa mga larong shooter, mga larong pangkompetensya, o mga karanasan sa VR, ang mabagal na pagtugon sa audio ay nangangahulugan ng pagkawala ng mga pangunahing pahiwatig ng tunog (mga yabag, putok ng baril, mga alerto) o pagpansin na ang aksyon at tunog ng controller ay hindi magkatugma, na sumisira sa immersion; para sa mga kasong ito, kapaki-pakinabang na matutunan kung paano sukatin ang latency sa mga video game at kumilos nang naaayon.

Sa mas teknikal na termino, karaniwang may pagkakaiba sa pagitan ng playback latency, capture latency, round-trip latency, at latency na nauugnay sa paghawak (halimbawa, paghawak sa screen at pakikinig sa isang tugon ng tunog). Ang lahat ng ito ay pinagsama-sama, at mahalagang maunawaan ang mga ito upang malaman kung saan napupunta ang ating oras.

Mga uri ng latency sa audio path

Sa loob ng Windows audio stack, maraming konsepto ang ginagamit upang ilarawan ang mga pagkaantala sa bawat yugto ng landas ng tunog . Hindi lamang ito isang akademikong bagay: ang bawat uri ng latency ay may magkakaibang sanhi at iba't ibang paraan upang mabawasan ang mga ito.

Ang playback latency ay ang pagkaantala sa pagitan ng paghahatid ng application ng audio buffer para sa playback at kapag naririnig mo ito sa pamamagitan ng iyong mga speaker o headphone . Ang laki ng buffer, format conversion, at anumang mga epektong inilapat habang isinasagawa ang pag-playback ay may papel na ginagampanan.

Ang capture latency, sa kabilang banda, ay ang oras na kinakailangan para makarating ang audio na nakuha mula sa mikropono sa application . Saklaw nito ang oras mula sa pagpasok ng tunog sa transducer, pagdaan sa interface, sa driver, at sa audio engine, hanggang sa mabasa ng software ang bloke ng data na iyon.

Ang tinatawag na round-trip latency ay ang kabuuan ng pareho: pagkuha, pagproseso sa app, at pag-playback sa pamamagitan ng mga speaker . Ito ang talagang mahalaga sa mga sitwasyon tulad ng pagsubaybay sa isang DAW, kung saan ka nagpapatugtog, ang signal ay dumadaan sa computer, at bumabalik sa iyong mga tainga.

Sa mga touch interface, madalas ding usapan ang touch-to-application at touch-to-sound latency: ang oras sa pagitan ng pag-tap sa screen, pagproseso ng event, at pagtugon ng system gamit ang audio . Para sa mga virtual na instrumento o creative app sa mga Windows tablet o convertible device, kailangang maging maikli hangga't maaari ang chain na ito.

Paano ina-assemble ang Windows audio stack

Sa ilalim ng WASAPI, ASIO, at mga katulad nito, ang Windows ay may audio stack na may central engine na naghahalo ng mga stream, naglalapat ng mga effect, nagre-rescale ng mga format, at nakikipag-ugnayan sa mga driver . Ang pag-unawa sa pathway na ito ay nakakatulong upang makita kung saan nakukuha at nawawala ang latency.

Habang nagpe-playback, isinusulat ng application ang audio sa isang buffer na inilalantad ng API. Binabasa ng Windows audio engine ang data na ito, pinoproseso ito (kabilang ang mga effect sa anyo ng mga APO, o mga audio processing object), at pagkatapos ay inilalagay ito sa isa pang buffer na gagamitin ng driver upang ipadala sa hardware.

Ang latency na nauugnay sa mga APO na ito ay nakadepende sa pagprosesong ginagawa ng mga ito (equalization, noise cancellation, 3D effects, atbp.) . Kung mas kumplikado ang algorithm at mas malaki ang dami ng state na kailangan nitong maipon, mas maraming sample ang kakailanganin nitong iimbak sa isang buffer, at mas malaki ang delay.

Bago ang Windows 10, ang simpleng pagdaan sa audio engine ay nagdaragdag ng humigit-kumulang 12 ms sa floating-point data at humigit-kumulang 6 ms sa integer data habang nagpe-playback . Simula noong Windows 10, ang prosesong ito ay lubos na na-optimize at ngayon ay tumatagal ng humigit-kumulang 1,3 ms, anuman ang uri ng data.

Pagkatapos ng pagproseso, inilalagay ng engine ang resulta sa isang buffer na ang haba ay mayroon ding direktang epekto. Sa mga mas lumang sistema, ang buffer na ito ay nakatakda sa humigit-kumulang 10 ms . Sa mga modernong bersyon, ang audio driver ay maaaring magdeklara ng iba't ibang sinusuportahang laki at payagan ang mas maliliit na halaga, tulad ng 2-3 ms.

Sa pagkuha, may katulad na nangyayari, ngunit sa kabaligtaran: kinukuha ng hardware ang signal mula sa mikropono , maaaring maglapat ng mga epekto (AGC, echo cancellation, atbp.), ibinubuhos ng controller ang data na iyon sa isang buffer, at kinokolekta at pinoproseso ito ng audio engine gamit ang sarili nitong mga APO bago ito gawing available sa application.

Sa mga mas lumang bersyon, ang audio engine ay nagdagdag ng humigit-kumulang 6 ms upang makuha ang oras para sa floating-point data at halos 0 ms para sa mga integer . Simula noong Windows 10, ang kontribusyon na ito ay nabawasan na sa punto kung saan ito ay halos bale-wala na. Gayunpaman, ang mga buffer sa driver at hardware ay nakakatulong pa rin sa kabuuang oras.

Nariyan din ang dedicated audio stack mode. Kung magbubukas ang isang app ng endpoint sa dedicated mode, nilalaktawan nito ang mixing engine at direktang nakikipag-ugnayan sa hardware buffer . Lalo nitong binabawasan ang latency, ngunit ang kapalit nito ay walang ibang programa ang maaaring sabay na gumamit ng input o output device na iyon.

ASIO, eksklusibong mode, at kung bakit lubos na bumuti ang WASAPI

Sa loob ng maraming taon, ang karaniwang paraan upang makamit ang mababang latency sa produksyon ng musika ay ang paggamit ng ASIO o mga device sa dedicated mode . Gamit ang ASIO, ang DAW ay halos direktang nakikipag-ugnayan sa driver ng gumawa ng interface, nang walang system mixer sa pagitan.

Ang problema ay may mga disbentaha ang pamamaraang ito: kadalasan ay nangangailangan ito ng mga partikular na third-party driver , kailangang handa ang software na makipag-ugnayan sa API na iyon, at, sa pangkalahatan, ang audio ng system (browser, mga laro, mga manlalaro) ay hindi isinasama o kailangan mong gumamit ng mga kumplikadong workaround para i-ruta ito.

Samantala, ang eksklusibong mode ng WASAPI ay nag-aalok ng katulad na bagay: ang daloy ng trabaho ng app ay halos direktang napunta sa device . Ngunit muli, nawalan ng access ang ibang mga application sa puntong iyon, na hindi gaanong maginhawa kapag gusto mong paghaluin ang mga DAW sa mga video sa YouTube, Discord, at iba pa.

Upang maiwasan ang pagpilit sa pagitan ng latency at flexibility, pinagbuti ng Microsoft ang Windows 10 shared stack upang mapababa ang latency kahit na walang eksklusibong paggamit . Ginawang mas magaan ang engine at, higit sa lahat, idinagdag ang kakayahang makipag-ayos ng mas maliliit na laki ng buffer sa pagitan ng app at ng driver.

Bukod pa rito, mayroong espesyal na resource management mode: kapag ang isang application ay nagsimulang gumana gamit ang napakaikling buffer, inuuna ng Windows ang mga thread na nauugnay sa audio stream na iyon at pinipigilan ang iba pang mga gawain ng system na makagambala sa pagproseso sa mga kritikal na sandali.

Mga setting ng latency ng WASAPI para sa mga gumagamit ng DAW at streaming

Mula sa pananaw ng end-user, ang WASAPI ay inihaharap bilang isa sa mga opsyon sa audio device sa maraming DAW at mga programa sa pagre-record . Sa Reaper, halimbawa, karaniwan ang paghahambing sa pagitan ng mga latency ng ASIO at WASAPI (kapwa sa eksklusibo at nakabahaging mga mode).

Sa ilang mga kaso, ang paglipat mula sa ASIO patungo sa nakalaang WASAPI ay maaaring makamit ang mas mababang latency kaysa sa ASIO driver ng tagagawa , basta't maayos na na-configure ang hardware at Windows driver. Hindi ito ang pinakakaraniwang sitwasyon, ngunit maaari itong mangyari, at kapag nangyari ito, mauunawaan na ayaw bumalik ng user sa ASIO.

Gayunpaman, kapag lumilipat sa nakabahaging WASAPI, maaaring lumitaw ang mga distortion, pag-click, o artifact kapag nagpe-playback o kumukuha ng audio mula sa DAW , habang ang ibang mga tunog ng system (browser, mga laro) ay tumutugtog nang walang problema. Kadalasan ito ay dahil sa mga hindi pagtutugma ng format, labis na agresibong buffering, o sapilitang mga conversion.

Isang tipikal na conflict ang nangyayari kapag pinipilit ng system ang device na gumana sa isang bit depth format na naiiba sa aktwal na sinusuportahan ng interface . Halimbawa, maaaring nagpapakita ang WASAPI ng 24 bits sa DAW dialog, habang ang Windows sound panel ay nag-aalok lamang ng 16 bits sa lahat ng sample rate nito.

Sa mga ganitong pagkakataon, upang maiwasan ang mga distortion sa shared WASAPI, ipinapayong suriin ang bit depth at sampling rate na naka-configure bilang default sa mga opsyon sa tunog ng Windows , at tiyaking gumagamit ang DAW ng format na tugma sa aktwal na sinusuportahan ng interface.

Sa ibang konteksto, tulad ng pagre-record ng mga voice-over gamit ang USB microphone sa mga simpleng application o tool tulad ng Audacity, ang WASAPI ay pangunahing ginagamit upang makuha ang sariling audio ng system o ang output ng Windows mixer , sa halip na makamit ang pinakamababang posibleng latency.

Latency, buffers, at persepsyon ng tao

Ang latency ay karaniwang sinusukat sa milliseconds, at sa pagsasagawa, sa ibaba ng humigit-kumulang 10 ms, ang pagkaantala ay itinuturing na halos hindi mahahalata ng karamihan ng mga tao . Sa pagitan ng 10 at 20 ms, nagsisimula itong maging kapansin-pansin sa mga sensitibong gawain, at higit pa riyan, ito ay nagiging malinaw na nakakainis.

Kapag nakikinig ka sa iyong sarili gamit ang headphone habang nagsasalita, ang anumang latency na higit sa 10 ms ay nagsisimulang lumikha ng pakiramdam na "internal echo" . Kung ito ay tumaas sa 30 o 40 ms, karamihan sa mga tao ay nalilito, humihinto sa pagsasalita, o nauuwi sa pagtanggal ng kanilang mga headphone.

Kasabay nito, ang mga digital audio signal ay inilalarawan sa pamamagitan ng sampling frequency (sa Hz) at buffer size (sa mga sample) . Bilang sanggunian, ang 44.100 Hz ay ​​nangangahulugan na ang waveform ay nahahati sa 44.100 sample bawat segundo; ganoon din ang ginagawa ng 48.000 Hz sa 48.000 sample, at iba pa.

Ang buffer ay isang uri ng maliit na lugar ng imbakan ng data kung saan dumadaloy ang audio data. Kung mas malaki ito, mas malaki ang margin ng kaligtasan laban sa mga spike o interrupt ng CPU , ngunit kapalit ng pagdaragdag ng milliseconds sa kabuuang latency. Kung babawasan mo ito nang sobra, kailangang gumising nang mas madalas ang sistema upang mapunan ito at mas madaling kapitan ng mga dropout o glitch.

Samakatuwid, kapag kino-configure ang isang device sa isang DAW o streaming app, ang karaniwang problema ay ang pumili ng buffer size na sapat na mababa upang hindi mapansin ang delay , ngunit hindi rin gaanong mababa para magsimula ang mga pag-click o pag-drop habang ginagawa ang aktwal na trabaho.

Paano bawasan ang latency ng audio sa Windows gamit ang WASAPI

Upang mapabuti ang karanasan sa WASAPI at, sa pangkalahatan, sa audio sa Windows, may ilang mga hakbang na dapat ilapat o kahit man lang suriin, kapwa sa antas ng hardware, software at system.

Ang unang hakbang ay tiyaking maayos na naka-install at napapanahon ang iyong audio hardware (interface, integrated sound card, USB microphones) at ang mga driver nito . Marami sa mga low-latency na pagpapabuti sa Windows 10 ay umaasa sa mga DDI at mga property na makikita lamang sa mga modernong driver; ang pag-diagnose ng latency gamit ang LatencyMon at pagtukoy ng mga isyu sa driver ay isang inirerekomendang gawain.

Sa industriya ng musika, ang karaniwang gawain ay nananatiling gumamit ng mga interface na may mataas na kalidad na ASIO driver kapag nagtatrabaho sa mga DAW, virtual na instrumento, o mga kumplikadong mix . Patuloy na nag-aalok ang ASIO ng pinong-tuning na kontrol sa mga laki ng buffer at sa pangkalahatan ay matatag kung ang PC ay nakatuon sa audio at hindi napapailalim sa overclocking o iba pang mabibigat na gawain.

Gayunpaman, sa streaming at paglalaro, nagiging hindi praktikal ang ASIO dahil karamihan sa mga application (mga laro, OBS, browser) ay gumagamit ng mga native na Windows driver (DirectSound, WASAPI). Kapag pinagsasama ang mga source na ito, mas mainam na manatili sa loob ng native ecosystem ng operating system.

Isang tuntunin na bihirang mabigo ay ang pag-iwas sa pagkonekta ng mas maraming device at programa kaysa sa kinakailangan sa signal path . Ang bawat analog-to-digital na conversion, bawat hakbang sa isang effects processor, o bawat paglipat mula sa isang app patungo sa isa pa ay nagdaragdag ng kaunting pagkaantala at panganib ng mga hindi pagtutugma.

Halimbawa, ang pagsasalita sa isang XLR microphone na nakakonekta sa isang nakalaang interface na may direktang paghahalo ng hardware ay hindi katulad ng paggamit ng USB microphone, software voice changer, virtual audio router, at USB gaming headphones . Sa pangalawang kaso, ang pinagsama-samang epekto ay hindi maiiwasang magdudulot ng malaking pagtaas ng latency.

Latency at mga partikular na pagpapabuti sa Windows 10 at mas bago

Hindi lamang pinahusay ng Microsoft ang audio engine sa Windows 10; nagdagdag din ito ng mga mekanismo para sa mga application at driver upang magtulungan upang mabawasan ang round-trip latency nang hindi ganap na isinasakripisyo ang flexibility ng shared stack.

Una, kahit hindi binabago ang code, maraming application ang nakakita ng pagbawas ng round-trip latency na nasa pagitan ng 4,5 at 16 ms kumpara sa Windows 8.1 , dahil lamang sa mga internal engine optimization. Ang mga gumagamit ng floating-point data ang higit na nakikinabang.

Pangalawa, kung ang sistema ay may mga na-update na driver, maaari nitong i-advertise ang mga laki ng buffer na mas maliit kaysa sa karaniwang 10 ms . Pinapayagan nito ang mga application na nangangailangan ng mababang latency na makipag-ayos sa mga halagang 5 ms, 3 ms, 1 ms, atbp., para sa parehong pag-playback at pagkuha.

Bukod pa rito, kapag ang isang app ay nagsimulang gumana nang may napakaliit na buffer, ina-activate ng Windows ang isang resource management mode na inuuna ang audio subsystem : pinoprotektahan nito ang mga thread ng engine, driver, at mga app na minarkahan bilang audio critical upang mabawasan ang mga pagkaantala at pagkabigo.

Nangangahulugan ito na, kung bubuo ka ng isang app na nangangailangan ng mabilis na tugon, maaari kang umasa sa bagong imprastraktura upang makamit ang napakababang latency nang hindi isinusuko ang shared mode, basta't sinusuportahan ito ng hardware.

AudioGraph: ang modernong API para sa paglikha at multimedia

Ang AudioGraph ay ang Universal Windows Platform API na idinisenyo para sa mga interactive at senaryo ng paglikha ng musika, na nag-aalok ng mas madaling gamiting abstraction layer kaysa sa direktang paggamit ng WASAPI. Ito ay makukuha sa C++, C#, JavaScript, at iba pang .NET na wika.

Para sa mga layuning mababa ang latency, inilalantad ng AudioGraph ang isang property na tinatawag na AudioGraphSettings::QuantumSizeSelectionMode , na nagbibigay-daan sa iyong tukuyin kung gusto mo ang default na laki ng buffer ng system, ang pinakamababang posibleng latency, o isang partikular na value na malapit sa ninanais.

Maaari itong i-configure upang gamitin ang default na laki ng buffer (humigit-kumulang 10 ms), upang piliin ang minimum na sinusuportahan ng audio driver , o upang subukang mapalapit sa bilang ng mga sample na ninanais ng app sa bawat processing quantum.

Ipinapakita ng mga opisyal na halimbawa kung paano, sa ilang linya lamang ng code, makakagawa ka ng low-latency audio graph sa pamamagitan lamang ng pagpili sa LowestLatency mode . Sinusuri ng opsyong ito kung aling mga sukat ang sinusuportahan ng device at pinipili ang pinakamalakas na posibleng laki nang hindi lumalagpas sa pinapayagang mga limitasyon.

Pinangangasiwaan din ng AudioGraph ang pamamahala ng mga audio thread nang may prayoridad sa loob , kaya hindi kailangang tahasang pumili ng MMCSS ang developer o direktang makipagtulungan sa mga real-time na pila upang makinabang mula sa low-latency mode ng system.

WASAPI at IAudioClient3: mahusay na pagkontrol ng periodicity

Para sa mga nangangailangan ng mas mababang antas ng kontrol, mga partikular na functionality, o mas mababang latency kaysa sa mga nakakamit ng AudioGraph , pinalawak ng Microsoft ang WASAPI gamit ang isang bagong interface: IAudioClient3, na hango sa kilalang-kilala nang IAudioClient2.

Nagdaragdag ang interface na ito ng mga method para i-query ang kasalukuyang format at periodicity ng audio engine sa shared mode , kunin ang range ng mga period na pinapayagan para sa isang partikular na format, at buksan ang mga shared stream na may partikular na periodicity, sa halip na tanggapin ang default na value.

Sa pagsasagawa, pinapayagan nito ang app na malaman kung aling mga laki ng buffer ang legal (mga multiple ng isang pundamental na panahon sa pagitan ng minimum at maximum) at pumili ng isang partikular na halaga na nagbabalanse sa katatagan at latency ayon sa mga pangangailangan nito.

Gamit ang IAudioClient3, maaari mo ring tukuyin na dapat gamitin ng stream ang format na tinukoy ng application nang hindi nag-resample sa engine , basta't sinusuportahan ng device ang eksaktong format na iyon. Naiiwasan nito ang mga intermediate conversion na maaaring magdagdag ng komplikasyon at bahagyang pagkaantala.

Bukod pa rito, inirerekomenda ng Microsoft na ang mga WASAPI application na nangangailangan ng mababang latency ay lumikha ng kanilang mga gawain sa pagproseso sa pamamagitan ng Real-Time Work Queue (RT Work Queue) o Media Foundation queues , na tinatatak ang mga ito bilang "Audio" o "ProAudio" sa halip na maglunsad ng sarili nilang mga hindi koordinado na thread.

Ang paglalagay ng label na ito ay nagbibigay-daan sa Windows na sentralisadong pamahalaan ang mga prayoridad at affinity ng mga thread na ito sa loob ng espesyal nitong audio mode, na binabawasan ang panganib ng isa pang subsystem na makagambala sa mga ito sa gitna ng pagproseso ng isang masikip na buffer.

Mga kinakailangang pagpapabuti sa mga low-latency driver

Ang bahagi ng user software ay kalahati pa lamang ng kwento. Para tunay na gumana ang isang sistema gamit ang mga buffer na ilang millisecond sa ilalim ng pinakamainam na mga kondisyon , kailangan ding gawin ng mga audio driver ang kanilang bahagi.

Simula sa Windows 10, maaaring ideklara ng mga driver, sa pamamagitan ng mga partikular na katangian, ang ganap na minimum na laki ng buffer na sinusuportahan nila sa bawat processing mode . Kasama sa impormasyong ito ang mga pangkalahatang paghihigpit at mga partikular na limitasyon para sa default na mode, cinema mode, atbp.

Halimbawa, maaaring tukuyin ng isang driver ang isang absolute minimum na 2 ms, ngunit sa default na processing mode, ang epektibong laki ng sample ay maaaring 128 sample sa 48 kHz (humigit-kumulang 3 ms). Iginagalang ng audio stack ang mga limitasyong ito at hindi kailanman susubukang bumaba sa tinukoy na minimum.

Bukod sa laki ng buffer, may mga DDI na nagpapadali para sa controller na tumpak na iulat kung aling bahagi ng buffer ang libre o puno, nagbibigay ng eksaktong mga timestamp batay sa throughput counter, at, sa ilang mga sitwasyon, nagda-download ng data nang mas mabilis kaysa sa real-time kung mayroon itong naipon na impormasyon sa loob.

Ang mga kakayahang ito ay lalong kapaki-pakinabang sa mga disenyo na may mga kumplikadong DSP o mga di-maliit na paglilipat ng data sa pagitan ng memorya at hardware, kung saan ang posisyon ng stream at panloob na latency ay nakasalalay sa ilang mga intermediate block . Dapat isaalang-alang ng pagkalkula ng timestamp ang mga nakapirming pagkaantala upang maayos na maihanay ng system ang data.

Panghuli, upang maayos na maprotektahan ng Windows ang audio subsystem sa mga sitwasyong may napakababang latency, dapat irehistro ng mga driver ang kanilang mga streaming resources gamit ang PortCls : ang kanilang sariling mga interrupt at thread na ginagamit upang matiyak ang daloy ng data.

Maaaring gawin ang pagpaparehistrong ito kapag naglo-load ang driver o habang tumatakbo, at mandatoryo na ang lahat ng driver sa streaming chain ay lumahok sa iba't ibang paraan. Halimbawa, sa mga stack na may HDAudio bus, bahagi ng gawaing ito ay ginagawa mismo ng bus driver, habang ang miniport ay nagrerehistro ng sarili nitong mga thread.

Mga tool at pamamaraan para sa pagsukat ng latency sa Windows

Upang matukoy kung ang mga pagsasaayos ng WASAPI at mga pagbabago sa driver ay talagang nakakagawa ng pagkakaiba, karaniwang kasanayan na sukatin ang round-trip latency gamit ang mga test pulse na pinapatugtog sa mga speaker at kinukuha ng isang mikropono . Kinakalkula ng software ang pagkaantala sa pagitan ng transmission at reception, at kung makakakita ka ng mga micro-dropout, sulit na suriin kung paano partikular na sukatin ang DPC latency.

Ang metodolohiyang ito ay nagbibigay-daan sa iyo upang ihambing ang iba't ibang laki ng buffer, mga operating mode, at mga bersyon ng driver, basta't sinusuportahan ng audio device ang kinakailangang maliliit na saklaw ng buffer . Kung hindi, babalik ang system sa default na 10 ms na laki ng buffer. Para sa mas malalim na pagsusuri, maaari mong matutunan kung paano lubusang suriin ang Windows gamit ang WPR/WPA.

Sa mga system na may karaniwang HDAudio hardware, na-update ang generic na Microsoft HDAudio inbox driver upang suportahan ang mga laki ng sample sa pagitan ng 128 sample (humigit-kumulang 2,66 ms sa 48 kHz) at 480 sample (10 ms sa 48 kHz). Sa ilang mga kaso, ang pag-install ng generic na driver na ito ay maaaring maging kapaki-pakinabang para sa pagsubok.

Ang proseso ay kinabibilangan ng pagbubukas ng Device Manager , paghahanap ng device na kumakatawan sa mga internal speaker, at pagpilit na i-install ang Microsoft "High Definition Audio Device" driver sa halip na ang codec ng gumawa. Pagkatapos ng pag-restart, gagamitin ng system ang generic na driver na ito para sa endpoint na iyon.

Mainam na tandaan kung aling driver ang ginamit nang maaga upang maibalik mo ang pagbabago kung kinakailangan. Bagama't kapaki-pakinabang ang driver ng Microsoft para sa pag-eksperimento sa maliliit na laki ng buffer, ang driver ng gumawa ay karaniwang nag-aalok ng kalidad ng tunog o mga partikular na tampok na mas angkop sa hardware.

Mga pagkakaiba sa WASAPI, AudioGraph at praktikal na latency

Bagama't parehong umaasa ang parehong API sa iisang audio engine, sa pagsasagawa, ang AudioGraph at WASAPI ay hindi palaging magkapareho ang kilos pagdating sa latency , kahit na ginagamit ang parehong pinagbabatayan na laki ng buffer.

Sa disenyo, nagdaragdag ang AudioGraph ng latency buffer sa capture side upang i-synchronize ang playback at recording . Pinapasimple nito nang husto ang application code dahil tinitiyak nitong magkahanay ang parehong path, ngunit nagdaragdag ito ng ilang millisecond.

Sa playback path, kapag ang sistema ay gumagamit ng mga laki ng buffer na mas malaki sa humigit-kumulang 6 ms, maaaring magpakilala ang AudioGraph ng isa pang safety buffer , muli na may ideya ng pag-aalok ng isang matatag at mahuhulaang modelo ng pag-iiskedyul sa halaga ng kaunting dagdag na latency.

Sa kabilang banda, inilalantad ng WASAPI ang ruta nang may mas kaunting abstraksyon. Nangangahulugan ito ng mas maraming manu-manong trabaho para sa developer , ngunit kapalit nito, pinapayagan nito ang pag-maximize ng pagbawas ng latency sa ilalim ng ilang partikular na kondisyon, lalo na sa low-frequency shared mode at sa IAudioClient3.

Bukod pa rito, hindi tulad ng AudioGraph, pinapayagan ng WASAPI ang mas detalyadong pamamahala ng mga capture effect, ang paggamit ng raw processing, at koordinasyon sa iba pang mga API tulad ng Media Foundation , na nagbubukas ng pinto para sa mga partikular na pag-optimize sa mga propesyonal na proyekto.

Sa lahat ng pagkakataon, malinaw ang rekomendasyon ng Microsoft: huwag basta-basta gamitin ang raw processing mode . Ang pag-disable sa mga OEM effect ay maaaring magpabuti sa latency, ngunit maaari rin itong humantong sa hindi gaanong na-optimize na mga playback signal o mga capture format na mahirap hawakan para sa app.

Sa pagsasama-sama ng lahat ng ito, nagiging malinaw na ang landas tungo sa pagiging dalubhasa sa mga setting ng latency ng WASAPI ay nakasalalay sa lubusang pag-unawa sa Windows stack, sa gawi ng iyong hardware, at sa mga available na API. Doon mo lamang matutukoy ang mga lugar kung saan tunay na nakukuha (o nawawala) ang bawat millisecond at maaayos ang configuration upang matugunan ang mga partikular na pangangailangan ng bawat application, nang hindi isinasakripisyo ang katatagan o kalidad ng tunog.