Tetapan Latensi WASAPI dalam Windows: Panduan Lengkap

Jika anda bekerja dengan audio pada Windows, lambat laun anda akan menghadapi kependaman WASAPI dan perbandingan yang tidak berkesudahan dengan ASIO dan WASAPI . Sesiapa yang merakam dalam DAW, menstrim secara langsung, bermain permainan dalam talian atau menghasilkan muzik tahu bahawa kelewatan beberapa milisaat boleh merosakkan rakaman, mengganggu suara atau menjadikan permainan sebagai satu dugaan.

Dalam versi Windows 10 dan versi yang lebih baharu, Microsoft telah menambah baik susunan audionya dengan ketara, dan hari ini, kependaman yang jauh lebih rendah boleh dicapai dengan WASAPI dalam mod kongsi atau eksklusif , tanpa mengorbankan audio pelayar atau audio daripada aplikasi lain. Kuncinya ialah memahami cara susunan berfungsi, apa yang telah berubah, batasan perkakasan yang dikenakannya dan parameter yang boleh kita laraskan (sebagai pengguna atau pembangun) untuk mengurangkan milisaat tambahan tersebut.

Apakah latensi audio dan mengapa ia sangat penting?

Apabila kita bercakap tentang kependaman audio, kita merujuk kepada masa yang berlalu dari masa bunyi dijana sehingga anda mendengarnya atau aplikasi anda menerimanya . Masa ini diukur dalam milisaat, dan walaupun ia mungkin kelihatan hampir tidak penting di atas kertas, dalam praktiknya ia membuat perbezaan antara pengalaman yang lancar dan sesuatu yang sama sekali tidak selesa.

Dalam penerbitan dan rakaman muzik , seorang pemain instrumental perlu mendengar diri mereka sendiri hampir serta-merta semasa bermain . Jika setiap not mengambil masa berpuluh-puluh milisaat untuk kembali melalui fon kepala, otak mula bergelut dengan apa yang didengar dan dirasai, dan mengekalkan irama menjadi satu dugaan.

Dalam penstriman , podcast dan panggilan video, latensi boleh menyebabkan ketidakpadanan antara video dan audio, gema yang menjengkelkan dan rasa "bercakap ke dinding ." Suara anda sendiri tertangguh selama beberapa milisaat di fon kepala akan membebankan pembesar suara, menyebabkan tersandung dan kedengaran tidak semula jadi kepada pendengar.

Bagi pemain permainan video, terutamanya dalam permainan tembak-menembak, permainan kompetitif atau pengalaman VR, tindak balas audio yang perlahan bermaksud kehilangan isyarat bunyi utama (langkah kaki, tembakan, amaran) atau perasan bahawa tindakan dan bunyi pengawal tidak segerak, merosakkan rendaman; untuk kes ini, adalah berguna untuk mempelajari cara mengukur kependaman dalam permainan video dan bertindak sewajarnya.

Dalam istilah yang lebih teknikal, perbezaan biasanya dibuat antara latensi main balik, latensi tangkapan, latensi perjalanan pergi balik dan latensi yang berkaitan dengan sentuhan (contohnya, menyentuh skrin dan mendengar respons bunyi). Semua ini digabungkan, dan adalah penting untuk memahaminya untuk mengetahui ke mana masa kita pergi.

Jenis kependaman dalam laluan audio

Dalam susunan audio Windows, beberapa konsep digunakan untuk menggambarkan kelewatan pada setiap peringkat laluan bunyi . Ini bukan sekadar perkara akademik: setiap jenis kependaman mempunyai punca yang berbeza dan cara yang berbeza untuk mengurangkannya.

Latensi main balik ialah kelewatan antara masa aplikasi menghantar penimbal audio untuk main balik dan masa anda mendengarnya melalui pembesar suara atau fon kepala anda . Saiz penimbal, penukaran format dan sebarang kesan yang digunakan di sepanjang proses, semuanya memainkan peranan.

Sebaliknya, latensi tangkapan ialah masa yang diambil oleh audio yang ditangkap daripada mikrofon untuk sampai ke aplikasi . Ia merangkumi masa dari masa bunyi memasuki transduser, melalui antara muka, pemacu dan enjin audio, sehingga perisian boleh membaca blok data tersebut.

Apa yang dipanggil latensi perjalanan pergi balik ialah jumlah kedua-duanya: merakam, memproses dalam aplikasi dan memainkan semula melalui pembesar suara . Itulah yang benar-benar penting dalam senario seperti pemantauan dalam DAW, di mana anda bermain, isyarat melalui komputer dan kembali ke telinga anda.

Dalam antara muka sentuh, terdapat juga perbincangan yang kerap tentang latensi sentuh-ke-aplikasi dan sentuh-ke-bunyi: masa antara mengetik skrin, peristiwa sedang diproses dan sistem bertindak balas dengan audio . Untuk instrumen maya atau aplikasi kreatif pada tablet Windows atau peranti boleh tukar, rantai ini perlu sesingkat mungkin.

Cara susunan audio Windows dipasang

Di bawah WASAPI, ASIO dan sebagainya, Windows mempunyai susunan audio dengan enjin pusat yang mencampurkan strim, menggunakan kesan, mengubah skala format dan berkomunikasi dengan pemacu . Memahami laluan ini membantu melihat di mana latensi diperoleh dan hilang.

Semasa main balik, aplikasi menulis audio ke penimbal yang didedahkan oleh API. Enjin audio Windows membaca data ini, memprosesnya (termasuk kesan dalam bentuk APO atau objek pemprosesan audio), dan kemudian membuangnya ke penimbal lain yang akan digunakan oleh pemacu untuk dihantar ke perkakasan.

Kependaman yang berkaitan dengan APO ini bergantung pada pemprosesan yang dilakukannya (penyamaan, pembatalan hingar, kesan 3D, dll.) . Semakin kompleks algoritma dan semakin besar jumlah keadaan yang perlu dikumpulkannya, semakin banyak sampel yang perlu disimpannya dalam penimbal, dan semakin besar kelewatan.

Sebelum Windows 10, hanya melalui enjin audio menambahkan sekitar 12 ms kepada data titik apungan dan kira-kira 6 ms kepada data integer semasa main balik . Sejak Windows 10, proses ini telah dioptimumkan secara drastik dan kini mengambil masa sekitar 1,3 ms, tanpa mengira jenis data.

Selepas pemprosesan, enjin meletakkan hasil dalam penimbal yang panjangnya juga mempunyai kesan langsung. Dalam sistem lama, penimbal ini ditetapkan pada sekitar 10 ms . Dalam versi moden, pemacu audio boleh mengisytiharkan saiz yang disokong berbeza dan membenarkan nilai yang lebih kecil, seperti 2-3 ms.

Dalam tangkapan, sesuatu yang serupa berlaku, tetapi secara terbalik: perkakasan mengambil isyarat daripada mikrofon , boleh menggunakan kesan (AGC, pembatalan gema, dll.), pengawal menuangkan data tersebut ke dalam penimbal, dan enjin audio mengumpul dan memprosesnya dengan APO sendiri sebelum menjadikannya tersedia untuk aplikasi.

Dalam versi lama, enjin audio menambah kira-kira 6 ms untuk merakam masa bagi data titik apungan dan hampir 0 ms untuk integer . Sejak Windows 10, sumbangan ini telah dikurangkan sehingga ia boleh diabaikan. Walaupun begitu, penimbal dalam pemacu dan perkakasan masih menyumbang kepada keseluruhan masa.

Terdapat juga mod tindanan audio khusus. Jika aplikasi membuka titik akhir dalam mod khusus, ia akan memintas enjin pencampuran dan berkomunikasi secara langsung dengan penimbal perkakasan . Ini seterusnya meminimumkan kependaman, tetapi imbangannya ialah tiada program lain yang boleh menggunakan peranti input atau output tersebut secara serentak.

ASIO, mod eksklusif, dan mengapa WASAPI telah banyak bertambah baik

Selama bertahun-tahun, cara standard untuk mencapai kependaman rendah dalam penerbitan muzik adalah dengan menggunakan ASIO atau peranti dalam mod khusus . Dengan ASIO, DAW berkomunikasi hampir secara langsung dengan pemacu pengeluar antara muka, tanpa pengadun sistem di antaranya.

Masalahnya ialah pendekatan ini mempunyai kelemahannya: ia biasanya memerlukan pemacu pihak ketiga tertentu , perisian perlu bersedia untuk berkomunikasi dengan API tersebut dan, secara amnya, audio sistem (pelayar, permainan, pemain) diabaikan atau anda perlu menggunakan penyelesaian yang kompleks untuk menghalakannya.

Sementara itu, mod eksklusif WASAPI menawarkan sesuatu yang serupa: aliran kerja aplikasi hampir terus ke peranti . Tetapi sekali lagi, aplikasi lain kehilangan akses pada ketika itu, yang tidak begitu mudah apabila anda ingin menggabungkan DAW dengan video YouTube, Discord dan sebagainya.

Untuk mengelakkan memaksa pilihan antara kependaman dan fleksibiliti, Microsoft menambah baik susunan kongsi Windows 10 untuk mengurangkan kependaman walaupun tanpa penggunaan eksklusif . Enjin telah dijadikan lebih ringan dan, yang paling penting, keupayaan untuk merundingkan saiz penimbal yang lebih kecil antara aplikasi dan pemacu telah ditambah.

Di samping itu, terdapat mod pengurusan sumber khas: apabila aplikasi mula berfungsi dengan penimbal yang sangat pendek, Windows mengutamakan thread yang berkaitan dengan strim audio tersebut dan menghalang tugas sistem lain daripada mengganggu pemprosesan pada saat-saat kritikal.

Tetapan latensi WASAPI untuk pengguna DAW dan penstriman

Dari perspektif pengguna akhir, WASAPI dibentangkan sebagai salah satu pilihan peranti audio dalam banyak DAW dan program rakaman . Dalam Reaper, sebagai contoh, perbandingan antara latensi ASIO dan WASAPI (kedua-duanya dalam mod eksklusif dan kongsi) adalah perkara biasa.

Dalam sesetengah kes, bertukar daripada ASIO kepada WASAPI khusus boleh mencapai kependaman yang lebih rendah daripada pemacu ASIO pengeluar , dengan syarat perkakasan dan pemacu Windows dikonfigurasikan dengan betul. Ini bukanlah situasi yang paling biasa, tetapi ia boleh berlaku, dan apabila ia berlaku, difahami bahawa pengguna tidak mahu kembali kepada ASIO.

Walau bagaimanapun, apabila bertukar kepada WASAPI yang dikongsi, herotan, klik atau artifak mungkin muncul semasa memainkan semula atau merakam audio daripada DAW , manakala bunyi sistem lain (pelayar, permainan) dimainkan tanpa masalah. Ini biasanya disebabkan oleh ketidakpadanan format, penimbalan yang terlalu agresif atau penukaran paksa.

Satu konflik biasa berlaku apabila sistem memaksa peranti berfungsi dalam format kedalaman bit yang berbeza daripada yang sebenarnya disokong oleh antara muka . Contohnya, WASAPI mungkin mempersembahkan 24 bit dalam dialog DAW, manakala panel bunyi Windows hanya menawarkan 16 bit merentasi semua kadar sampelnya.

Dalam kes ini, untuk mengelakkan herotan dalam WASAPI yang dikongsi, adalah dinasihatkan untuk menyemak kedalaman bit dan kadar pensampelan yang dikonfigurasikan sebagai lalai dalam pilihan bunyi Windows dan memastikan bahawa DAW menggunakan format yang serasi dengan apa yang sebenarnya disokong oleh antara muka.

Dalam konteks lain, seperti merakam suara latar dengan mikrofon USB dalam aplikasi atau alat mudah seperti Audacity, WASAPI digunakan terutamanya untuk merakam audio sistem itu sendiri atau output pengadun Windows , dan bukannya untuk mencapai kependaman serendah mungkin.

Latensi, penimbal dan persepsi manusia

Kependaman biasanya diukur dalam milisaat, dan dalam praktiknya, di bawah kira-kira 10 ms, kelewatan dianggap hampir tidak dapat dilihat oleh kebanyakan orang . Antara 10 dan 20 ms, ia mula menjadi ketara dalam tugas sensitif, dan melebihi itu, ia menjadi jelas menjengkelkan.

Apabila anda mendengar diri anda melalui fon kepala semasa bercakap, sebarang latensi melebihi 10 ms mula mewujudkan perasaan "gema dalaman" . Jika ia meningkat kepada 30 atau 40 ms, kebanyakan orang akan keliru, berhenti bercakap atau akhirnya menanggalkan fon kepala mereka.

Pada masa yang sama, isyarat audio digital diterangkan oleh frekuensi persampelan (dalam Hz) dan saiz penimbal (dalam sampel) . Sebagai rujukan, 44.100 Hz bermaksud bentuk gelombang dibahagikan kepada 44.100 sampel sesaat; 48.000 Hz melakukan perkara yang sama dengan 48.000 sampel, dan sebagainya.

Penimbal ialah sejenis kawasan penyimpanan data kecil yang dilalui oleh data audio. Lebih besar saiznya, lebih besar margin keselamatan yang anda miliki terhadap lonjakan atau gangguan CPU , tetapi dengan kos menambah milisaat pada keseluruhan latensi. Jika anda mengurangkannya terlalu banyak, sistem perlu bangun lebih kerap untuk mengisinya semula dan lebih terdedah kepada gangguan atau gangguan.

Oleh itu, apabila mengkonfigurasi peranti dalam DAW atau aplikasi penstriman, dilema biasa adalah memilih saiz penimbal yang cukup rendah supaya kelewatan tidak ketara , tetapi tidak terlalu rendah sehingga klik atau penurunan bermula semasa kerja sebenar.

Cara mengurangkan latensi audio dalam Windows menggunakan WASAPI

Untuk meningkatkan pengalaman dengan WASAPI dan, secara amnya, dengan audio dalam Windows, terdapat beberapa langkah yang harus digunakan atau sekurang-kurangnya dikaji semula, baik pada peringkat perkakasan, perisian dan sistem.

Langkah pertama adalah memastikan perkakasan audio anda (antara muka, kad bunyi bersepadu, mikrofon USB) dan pemacunya dipasang dengan betul dan terkini . Kebanyakan penambahbaikan latensi rendah dalam Windows 10 bergantung pada DDI dan sifat yang hanya terdapat dalam pemacu moden; menggunakan LatencyMon untuk mendiagnosis latensi dan mengesan masalah pemacu adalah amalan yang baik.

Dalam industri muzik, amalan standard kekal menggunakan antara muka dengan pemacu ASIO berkualiti tinggi apabila bekerja dengan DAW, instrumen maya atau campuran kompleks . ASIO terus menawarkan kawalan yang ditala halus ke atas saiz penimbal dan secara amnya stabil jika PC dikhaskan untuk audio dan tidak tertakluk kepada overclocking atau tugas berat lain.

Walau bagaimanapun, dalam penstriman dan permainan, ASIO menjadi tidak praktikal kerana kebanyakan aplikasi (permainan, OBS, pelayar) menggunakan pemacu Windows asli (DirectSound, WASAPI). Apabila mencampurkan sumber-sumber ini, adalah lebih baik untuk kekal dalam ekosistem asli sistem pengendalian.

Satu peraturan yang jarang gagal adalah untuk mengelakkan rantaian lebih banyak peranti dan program daripada yang diperlukan dalam laluan isyarat . Setiap penukaran analog-ke-digital, setiap langkah melalui pemproses kesan atau setiap lompatan dari satu aplikasi ke aplikasi lain menambah sedikit kelewatan dan risiko ketidakpadanan.

Contohnya, bercakap ke dalam mikrofon XLR yang disambungkan ke antara muka khusus dengan pencampuran perkakasan langsung tidak sama seperti melalui mikrofon USB, penukar suara perisian, penghala audio maya dan fon kepala permainan USB . Dalam kes kedua, kesan kumulatif pasti menyebabkan latensi meningkat dengan ketara.

Kependaman dan penambahbaikan khusus dalam Windows 10 dan yang lebih baharu

Microsoft bukan sahaja telah menggilap enjin audio dalam Windows 10; ia juga telah menambah mekanisme untuk aplikasi dan pemacu berfungsi bersama bagi mengurangkan latensi perjalanan pergi balik tanpa mengorbankan sepenuhnya fleksibiliti susunan kongsi.

Pertama, walaupun tanpa mengubah kod, banyak aplikasi telah menyaksikan pengurangan antara 4,5 dan 16 ms dalam latensi perjalanan pergi balik berbanding Windows 8.1 , hanya disebabkan oleh pengoptimuman enjin dalaman. Aplikasi yang menggunakan data titik apungan mendapat manfaat paling banyak.

Kedua, jika sistem mempunyai pemacu yang dikemas kini, pemacu ini boleh mengiklankan saiz penimbal yang lebih kecil daripada 10 ms standard . Ini membolehkan aplikasi yang memerlukan kependaman rendah untuk merundingkan nilai 5 ms, 3 ms, 1 ms, dsb., untuk kedua-dua main balik dan tangkapan.

Di samping itu, apabila aplikasi mula beroperasi dengan penimbal yang sangat kecil, Windows mengaktifkan mod pengurusan sumber yang mengutamakan subsistem audio : ia melindungi thread enjin, pemacu dan aplikasi yang ditandakan sebagai audio kritikal untuk meminimumkan gangguan dan kegagalan.

Semua ini bermakna, jika anda membangunkan aplikasi yang memerlukan respons pantas, anda boleh bergantung pada infrastruktur baharu untuk mencapai kependaman yang sangat rendah tanpa melepaskan mod kongsi, dengan syarat perkakasan menyokongnya.

AudioGraph: API moden untuk penciptaan dan multimedia

AudioGraph ialah API Platform Windows Universal yang direka untuk senario interaktif dan penciptaan muzik, menawarkan lapisan abstraksi yang lebih mesra pengguna berbanding menggunakan WASAPI secara langsung. Ia tersedia dalam C++, C#, JavaScript dan bahasa .NET yang lain.

Untuk matlamat kependaman rendah, AudioGraph mendedahkan sifat yang dipanggil AudioGraphSettings::QuantumSizeSelectionMode , yang membolehkan anda menentukan sama ada anda mahukan saiz penimbal lalai sistem, kependaman terendah yang mungkin atau nilai tertentu yang hampir dengan yang dikehendaki.

Ia boleh dikonfigurasikan untuk menggunakan saiz penimbal lalai (sekitar 10 ms), untuk memilih minimum yang disokong oleh pemacu audio atau untuk cuba mendekati bilangan sampel yang dikehendaki oleh aplikasi dalam setiap kuantum pemprosesan.

Contoh rasmi menunjukkan bagaimana, hanya dengan beberapa baris kod, anda boleh mencipta graf audio latensi rendah hanya dengan memilih mod LowestLatency . Pilihan ini menyemak secara dalaman saiz yang disokong oleh peranti dan memilih saiz yang paling agresif tanpa melebihi had yang dibenarkan.

AudioGraph juga mengendalikan pengurusan thread audio secara dalaman dengan keutamaan , jadi pembangun tidak perlu memilih MMCSS secara eksplisit atau bekerja secara langsung dengan baris gilir masa nyata untuk mendapat manfaat daripada mod latensi rendah sistem.

WASAPI dan IAudioClient3: kawalan berkala yang baik

Bagi mereka yang memerlukan lebih banyak kawalan peringkat rendah, fungsi khusus atau latensi yang lebih rendah daripada yang dicapai oleh AudioGraph , Microsoft telah mengembangkan WASAPI dengan antara muka baharu: IAudioClient3, yang berasal daripada IAudioClient2 yang sudah terkenal.

Antara muka ini menambah kaedah untuk menanyakan format semasa dan berkala enjin audio dalam mod kongsi , mendapatkan julat tempoh yang dibenarkan untuk format tertentu dan membuka strim kongsi dengan berkala tertentu, dan bukannya menerima nilai lalai.

Dalam praktiknya, ini membolehkan aplikasi mengetahui saiz penimbal yang sah (gandaan tempoh asas antara minimum dan maksimum) dan memilih nilai tertentu yang mengimbangi kestabilan dan kependaman mengikut keperluannya.

Dengan IAudioClient3, anda juga boleh menentukan bahawa strim harus menggunakan format yang ditentukan oleh aplikasi tanpa pensampelan semula dalam enjin , dengan syarat peranti menyokong format yang tepat. Ini mengelakkan penukaran perantaraan yang boleh menambah kerumitan dan sedikit kelewatan.

Di samping itu, Microsoft mengesyorkan agar aplikasi WASAPI yang memerlukan kependaman rendah mencipta tugas pemprosesan mereka melalui Baris Gilir Kerja Masa Nyata (Baris Gilir Kerja RT) atau baris gilir Media Foundation , melabelkannya sebagai "Audio" atau "ProAudio" dan bukannya melancarkan thread mereka sendiri yang tidak diselaraskan.

Pelabelan ini membolehkan Windows mengurus keutamaan dan pertalian thread ini secara berpusat dalam mod audio khasnya, mengurangkan risiko subsistem lain mengganggu mereka di tengah-tengah pemprosesan penimbal yang ketat.

Penambahbaikan diperlukan dalam pemacu latensi rendah

Komponen perisian pengguna hanyalah separuh daripada cerita. Agar sistem benar-benar berfungsi dengan penimbal beberapa milisaat di bawah keadaan optimum , pemacu audio juga perlu memainkan peranan mereka.

Bermula dengan Windows 10, pemacu boleh mengisytiharkan, melalui sifat tertentu, saiz penimbal minimum mutlak yang disokongnya dalam setiap mod pemprosesan . Maklumat ini termasuk sekatan umum dan batasan khusus untuk mod lalai, mod pawagam, dsb.

Contohnya, pemacu mungkin menetapkan minimum mutlak 2 ms, tetapi dalam mod pemprosesan lalai, saiz sampel berkesan mungkin 128 sampel pada 48 kHz (kira-kira 3 ms). Tindanan audio mematuhi had ini dan tidak akan sekali-kali cuba berada di bawah minimum yang ditentukan.

Selain saiz penimbal, terdapat DDI yang memudahkan pengawal melaporkan dengan tepat bahagian penimbal yang kosong atau penuh, memberikan cap waktu yang tepat berdasarkan kaunter daya pemprosesan dan, dalam beberapa senario, memuat turun data lebih cepat daripada masa nyata jika ia telah mengumpulkan maklumat secara dalaman.

Keupayaan ini amat berguna dalam reka bentuk dengan DSP kompleks atau pemindahan data yang tidak remeh antara memori dan perkakasan, yang mana kedudukan strim dan latensi dalaman bergantung pada beberapa blok perantaraan . Pengiraan cap waktu mesti mengambil kira kelewatan tetap ini supaya sistem boleh menyelaraskan data dengan betul.

Akhir sekali, agar Windows dapat melindungi subsistem audio dengan betul dalam senario kependaman yang sangat rendah, pemacu mesti mendaftarkan sumber penstriman mereka dengan PortCls : gangguan dan thread mereka sendiri yang digunakan untuk memastikan aliran data.

Pendaftaran ini boleh dilakukan semasa pemacu dimuatkan atau semasa masa jalan, dan adalah wajib bagi semua pemacu dalam rantaian penstriman untuk mengambil bahagian dalam satu atau lain cara. Dalam susunan dengan bas HDAudio, sebagai contoh, sebahagian daripada kerja ini dilakukan oleh pemacu bas itu sendiri, manakala miniport mendaftarkan threadnya sendiri.

Alat dan teknik untuk mengukur kependaman dalam Windows

Untuk menentukan sama ada pelarasan WASAPI dan perubahan pemacu benar-benar membawa perubahan, amalan biasa adalah untuk mengukur latensi pergi balik menggunakan denyutan ujian yang dimainkan melalui pembesar suara dan ditangkap oleh mikrofon . Perisian ini mengira kelewatan antara penghantaran dan penerimaan, dan jika anda melihat mikro-putus, adalah wajar untuk menyemak cara mengukur latensi DPC secara khusus.

Metodologi ini membolehkan anda membandingkan saiz penimbal, mod operasi dan versi pemacu yang berbeza, dengan syarat peranti audio menyokong julat penimbal kecil yang diperlukan . Jika tidak, sistem akan kembali kepada saiz penimbal 10 ms lalai. Untuk analisis yang lebih mendalam, anda boleh mempelajari cara menganalisis Windows secara menyeluruh menggunakan WPR/WPA.

Pada sistem dengan perkakasan HDAudio standard, pemacu peti masuk Microsoft HDAudio generik telah dikemas kini untuk menyokong saiz sampel antara 128 sampel (kira-kira 2,66 ms pada 48 kHz) dan 480 sampel (10 ms pada 48 kHz). Dalam sesetengah kes, memasang pemacu generik ini mungkin berguna untuk pengujian.

Proses ini melibatkan pembukaan Pengurus Peranti , mencari peranti yang mewakili pembesar suara dalaman dan memaksa pemasangan pemacu "Peranti Audio Definisi Tinggi" Microsoft dan bukannya codec pengeluar. Selepas dimulakan semula, sistem akan menggunakan pemacu generik ini untuk titik akhir tersebut.

Adalah idea yang baik untuk mencatat pemacu yang digunakan terlebih dahulu supaya anda boleh mengembalikan perubahan jika perlu. Walaupun pemacu Microsoft berguna untuk bereksperimen dengan saiz penimbal yang kecil, pemacu pengeluar biasanya menawarkan kualiti bunyi atau ciri khusus yang lebih sesuai dengan perkakasan.

Perbezaan WASAPI, AudioGraph dan kependaman praktikal

Walaupun kedua-dua API bergantung pada enjin audio yang sama, dalam praktiknya AudioGraph dan WASAPI tidak selalunya bertindak sama dari segi kependaman , walaupun menggunakan saiz penimbal asas yang sama.

Secara reka bentuknya, AudioGraph menambah penimbal kependaman pada bahagian tangkapan untuk menyegerakkan main balik dan rakaman . Ini memudahkan kod aplikasi dengan ketara kerana ia memastikan kedua-dua laluan sejajar, tetapi ia menambah beberapa milisaat.

Dalam laluan main balik, apabila sistem menggunakan saiz penimbal yang lebih besar daripada kira-kira 6 ms, AudioGraph boleh memperkenalkan penimbal keselamatan yang lain , sekali lagi dengan idea untuk menawarkan model penjadualan yang stabil dan boleh diramal dengan kos sedikit latensi tambahan.

Sebaliknya, WASAPI mendedahkan laluan dengan kurang abstraksi. Ini bermakna lebih banyak kerja manual untuk pembangun , tetapi sebagai balasannya, ia membolehkan memaksimumkan pengurangan kependaman dalam keadaan tertentu, terutamanya dalam mod kongsi frekuensi rendah dan dengan IAudioClient3.

Tambahan pula, tidak seperti AudioGraph, WASAPI membolehkan pengurusan kesan tangkapan yang lebih terperinci, penggunaan pemprosesan mentah dan penyelarasan dengan API lain seperti Media Foundation , membuka pintu kepada pengoptimuman khusus dalam projek profesional.

Dalam semua kes, cadangan Microsoft adalah jelas: jangan gunakan mod pemprosesan mentah dengan mudah . ​​Melumpuhkan kesan OEM boleh meningkatkan kependaman, tetapi ia juga boleh menyebabkan isyarat main balik atau format tangkapan yang kurang dioptimumkan yang sukar dikendalikan oleh aplikasi.

Dengan menggabungkan semua ini, menjadi jelas bahawa jalan untuk menguasai tetapan kependaman WASAPI terletak pada pemahaman yang menyeluruh tentang susunan Windows, tingkah laku perkakasan anda dan API yang tersedia. Hanya dengan itu anda boleh menentukan kawasan di mana setiap milisaat benar-benar diperoleh (atau hilang) dan memperhalusi konfigurasi untuk memenuhi keperluan khusus setiap aplikasi, tanpa mengorbankan kestabilan atau kualiti bunyi.