Menggabungkan API kustom dan Windows
Objek pemrosesan audio (API), menyediakan pemrosesan sinyal digital berbasis perangkat lunak yang dapat disesuaikan untuk aliran audio Windows. Dimungkinkan untuk menggabungkan API yang disediakan Microsoft, dengan kode yang dikembangkan mitra, membungkus dan menyesuaikan fungsionalitas yang ada.
Lihat topik ini untuk informasi umum tentang API.
- Arsitektur Objek Pemrosesan Audio
- Menerapkan Objek Pemrosesan Audio
- Menerapkan Efek APO yang Dibongkar Perangkat Keras
API pertama kali diperkenalkan di Windows Vista dan Anda mungkin melihat referensi ke API sistem sebelumnya - sPO. Untuk informasi selengkapnya, lihat laporan resmi Efek Audio Kustom di Windows Vista . Laporan resmi ini dapat mereferensikan topik pengembangan COM dan UI yang lebih lama.
Cara menggabungkan API kustom dan Windows
Bagian ini berisi panduan untuk menerapkan API efek sistem audio kustom, dengan membuat pembungkus tipis di sekitar APO yang sesuai. Kustom APO mengacu pada implementasi IHV dari APO.
Ada dua jenis API, SFX (Stream) dan MFX (Mode). Dalam Windows 8.1, SFX disebut sebagai LFX (lokal) dan MFX disebut sebagai API GFX (global).
IHV dapat mengimplementasikan API efek sistem audio kustom untuk menggantikan API efek sistem audio kustom Windows SFX dan MFX. Secara umum, IHV atau OEM memiliki dua strategi dasar untuk menggabungkan API efek sistem audio kustom dengan API yang disediakan Windows. Strategi ini memberikan fleksibilitas IHV tentang bagaimana mereka mengintegrasikan efek kustom mereka dengan windows.
Replace
Kembangkan pemahaman terperinci tentang Windows APO yang ingin Anda ganti dan fitur-fiturnya. Gunakan pemahaman tersebut untuk mengimplementasikan APO kustom yang memanggil Windows APO dengan cara yang paling masuk akal bagi IHV dari perspektif pengalaman pengguna target mereka. Strategi ini paling cocok untuk IHV atau OEM yang ingin:
- Mengintegrasikan efek kustom mereka dengan efek Windows dengan lancar.
- Terapkan UI mereka sendiri untuk mengontrol efeknya dan efek yang diterapkan oleh API Windows.
Untuk informasi selengkapnya tentang menulis APO, lihat Objek Pemrosesan Audio Windows.
Pembungkus tipis
Tulis APO kustom sebagai pembungkus tipis di sekitar Windows APO. Strategi ini paling cocok untuk IHV atau OEM yang ingin:
- Tambahkan efek kustom mereka dengan cara yang paling sederhana.
- Minta UI Windows terus mengontrol efeknya.
IHV atau OEM yang memilih Strategi opsi pembungkus tipis, masih harus meninjau Objek Pemrosesan Audio Windows untuk mendapatkan pemahaman menyeluruh tentang efek sistem audio kustom Windows.
Catatan: Dengan IHV strategi pembungkus tipis tidak dapat menambahkan UI untuk mengontrol efek sistem audio kustom yang ditambahkan ke tab Peningkatan Windows. Hanya ada satu tab Penyempurnaan, dan harus tetap terkait dengan halaman properti untuk API Windows. UI IHV harus diimplementasikan dengan cara lain, seperti aplikasi Panel Kontrol terpisah.
Informasi pemrograman
Bagian ini mencakup masalah pemrograman umum yang harus ditangani menerapkan API kustom.
EFEK sistem audio kustom SFX(Stream) dan MFX(Mode) memiliki karakteristik umum berikut:
- Mereka harus terdaftar sebagai objek server dalam proses COM yang dapat diinstansiasi dengan menggunakan CoCreateInstance.
- CLSID masing-masing adalah
CLSID_CWMAudioLFXAPOdanCLSID_CWMAudioGFXAPOuntuk API SFX dan MFX. CLSID dideklarasikan dalam wmcodecdsp.h dan didefinisikan dalam wmcodecdspuuid.lib. - Mereka harus mendukung agregasi COM. Namun, agregasi tidak diharapkan digunakan dalam skenario efek sistem audio kustom, sehingga seharusnya tidak menimbulkan masalah yang signifikan.
Inisialisasi
APO kustom harus menginisialisasi APO Jendela dengan memanggil metode IAudioSystemEffects::Initialize-nya . Ini biasanya dilakukan dari metode Inisialisasi APO kustom. Argumen apa pun yang diteruskan ke metode Inisialisasi APO kustom harus diteruskan langsung ke Inisialisasi APO Windows. Ini memungkinkan APO untuk mengambil pengaturannya dari titik akhir dan penyimpanan properti Fx di struktur APOInitSystemEffects. Dimungkinkan untuk memiliki APO kustom mengambil pengaturan dan secara selektif meneruskannya ke APO, tetapi pada dasarnya strategi A.
Jika APO kustom menggantikan fitur, umumnya disarankan untuk menonaktifkan fitur yang sesuai pada APO. Namun, menonaktifkan fitur mungkin tidak benar-benar diperlukan, tergantung pada cara kerja fitur. Untuk menonaktifkan fitur, kueri APO untuk antarmuka IPropertyStore-nya dan panggil IPropertyStore::SetValue. Properti yang didukung oleh penyimpanan properti APO dijelaskan dalam "Properti IPropertyStore yang didukung." nanti dalam topik ini.
Untuk contoh cara berkomunikasi dengan penyimpanan properti APO efek sistem audio kustom Windows, lihat sampel di GitHub di: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO
Status fitur APO kueri
Jika APO kustom hanya menggantikan fitur efek audio Windows dan tidak memiliki UI konfigurasi atau penyimpanan pengaturannya sendiri, APO mungkin harus menentukan fitur apa yang diaktifkan pada APO yang sesuai.
Setidaknya ada dua cara untuk mendapatkan informasi ini:
Opsi A: Dengan langsung mengkueri penyimpanan properti Fx.
Opsi B: Secara tidak langsung, dengan membuat instans APO dan menggunakan antarmuka IPropertyStore-nya untuk mengkueri penyimpanan properti.
Opsi A
Opsi ini memiliki keuntungan yang dapat dilakukan tanpa membuat instans APO. Selain itu, jika APO kustom ingin memantau penyimpanan properti Fx, Opsi A adalah satu-satunya cara untuk menerima pemberitahuan perubahan properti on-the-fly. Untuk contoh Opsi A, lihat sampel "kompres".
Dengan Opsi A, APO kustom meminta penyimpanan properti titik akhir utama—bukan Fx—untuk PKEY_AudioEngine_DeviceFormat. Kemudian menggunakan masker saluran dari format tersebut sebagai PID untuk kunci properti yang digunakan untuk mengkueri penyimpanan properti Fx. GUID (fmtid) untuk kunci properti yang digunakan untuk mengkueri penyimpanan properti Fx adalah salah satu nilai XXX_XXX_KEY_GUID dari wmcodecdsp.h. Nama KEY_GUID sesuai dengan cara yang jelas dengan nama MFPKEY yang dibahas sebelumnya dalam topik ini.
Opsi B
Opsi ini memiliki keuntungan yang dapat menangani dengan benar kemungkinan bahwa Windows APO pada akhirnya dapat mengaktifkan beberapa fiturnya secara default jika properti yang sesuai di penyimpanan properti Fx tidak ada.
Dengan Opsi B, APO kustom hanya mengkueri APO untuk antarmuka IPropertyStore-nya dan memanggil IPropertyStore::GetValue dengan menggunakan salah satu kunci MFPKEY_XXX yang dibahas sebelumnya dalam topik ini.
Negosiasi format
Saat menerapkan APO SFX kustom yang membungkus APO SFX, jangan tentukan APO_FLAG_FRAMESPERSECOND_MUST_MATCH di properti pendaftaran APO kustom. Aturan ini harus diikuti apakah APO kustom dapat mengubah format saluran atau tidak. Jika SFX APO kustom menentukan bendera ini, itu akan mencegah SFX yang sesuai melakukan pengisian speaker, virtualisasi headphone, atau pengeliling virtual.
Implementasi SFX APO kustom harus menerapkan atau menimpa IAudioProcessingObject::IsInputFormatSupported. Implementasi IsInputFormatSupported kelas dasar tidak mungkin secara akurat mencerminkan serangkaian kemungkinan konversi saluran yang diterapkan oleh SFX APO kustom dan APO SFX.
Metode IsInputFormatSupported SFX APO kustom harus memanggil IsInputFormatSupported APO yang sesuai. Ini memastikan bahwa SFX APO menangani konversi saluran apa pun yang tidak ditangani oleh APO SFX kustom. Perhatikan bahwa APO SFX mungkin diperbarui untuk mendukung lebih banyak konversi dalam rilis Windows mendatang. Memanggil metode IsInputFormatSupported APO adalah salah satu cara untuk memastikan bahwa kumpulan konversi saluran yang didukung oleh APO kustom sepenuhnya berisi serangkaian konversi saluran yang didukung oleh SFX APO.
Apa yang harus dilakukan APO kustom dengan nilai pengembalian dari metode IsInputFormatSupported SFX APO tergantung pada konversi saluran apa, jika ada, SFX APO kustom mendukung.
Jika SFX APO kustom tidak mendukung konversi salurannya sendiri, metode IsInputFormatSupported dapat mengembalikan nilai yang dikembalikan oleh metode IsInputFormatSupported SFX APO langsung ke pemanggil. Misalnya, lihat sampel "swap" dan "compress".
Jika SFX APO kustom mendukung konversi salurannya sendiri, maka nilai pengembalian negatif—termasuk S_FALSE—dari metode IsInputFormatSupported SFX APO tidak selalu diterjemahkan ke dalam nilai pengembalian negatif kepada pemanggil. SFX APO kustom dapat, misalnya, mendukung konversi saluran yang tidak didukung oleh APO yang sesuai. Dalam hal ini, SFX APO kustom harus menggabungkan nilai pengembalian dari metode IsInputFormatSupported SFX APO dengan logikanya sendiri untuk menentukan input yang didukung. Perhatikan bahwa arti optimal "gabungkan" tergantung pada jenis konversi saluran mana yang harus diutamakan. Pendekatan terbaik tergantung pada desain implementasi kustom yang tepat.
Metode IsOutputFormatSupported pada APO SFX tidak menarik karena format output SFX APO adalah format campuran perangkat. Format ini didasarkan pada pertimbangan eksternal dan tidak dapat dipengaruhi oleh SFX APO atau format inputnya. Untuk alasan itu, sampel tidak mencoba menerapkan logika yang benar untuk IsOutputFormatSupported.
Pertimbangan di atas tidak berlaku untuk MFX API karena MFX APO tidak menerapkan fitur apa pun yang memerlukan atau menyiratkan perubahan format saluran. Untuk alasan itu, sampel MFX tidak melakukan hal khusus untuk IsInputFormatSupported atau IsOutputFormatSupported. Logika negosiasi format APO MFX kustom tidak terpengaruh oleh fakta bahwa ia membungkus MFX APO.
LockForProcess/UnlockForProcess
Metode IAudioProcessingObjectConfiguration::LockForProcess APO kustom harus memanggil metode yang sesuai pada APO. LockForProcess() adalah tempat yang baik untuk membuat keputusan mengenai urutan di mana berbagai tahap pemrosesan harus terjadi. Misalnya, dapat memutuskan apakah akan menerapkan pemrosesan APO kustom atau pemrosesan APO terlebih dahulu. Ketiga sampel memberikan contoh logika keputusan tersebut, dan komentar dalam sampel memberikan beberapa latar belakang. Namun, tidak mungkin untuk memberikan panduan umum sepenuhnya tentang subjek tersebut dalam dokumen ini karena akan memerlukan pengetahuan tentang fitur spesifik APO kustom dan bagaimana mereka dapat berinteraksi dengan fitur API.
GetLatency
Implementasi IAudioProcessingObject::GetLatency APO kustom harus memanggil GetLatency pada APO yang sedang dibungkus. Jika pemrosesan APO kustom menimbulkan latensi, itu harus menambahkannya ke hasil yang dikembalikan oleh APO sebelum mengembalikan nilai ke pemanggil.
APOProcess
Metode IAudioProcessingObjectRT::APOProcess APO kustom harus memanggil metode APOProcess APO sebelum, sesudah, atau bahkan selama pemrosesan. Keputusan tentang kapan harus memanggil APOProcess harus dibuat di LockForProcess, sehingga buffer perantara yang diperlukan dapat dialokasikan. API mendukung pemrosesan di tempat setiap kali format input dan outputnya identik. Dalam hal ini, APO kustom dapat melewati APO_CONNECTION_PROPERTY yang sama dengan properti koneksi input dan output untuk Windows APO. Namun, APO kustom tidak boleh menggunakan properti koneksi input APO kustom sebagai properti koneksi output untuk APO. Secara umum, API tidak boleh memodifikasi buffer input mereka.
Menangani kesalahan APO
Jika APO mengembalikan kesalahan ke APO kustom yang sesuai, APO kustom harus bertindak dari titik tersebut seolah-olah tidak ada APO. Sampel memperlakukan semua kesalahan APO setara dengan CoCreateInstance yang gagal membuat APO. Secara opsional, APO kustom dapat membatasi efek kesalahan dari metode LockForProcess APO ke sesi saat ini. Dengan kata lain, APO kustom tidak menggunakan APO selama panggilan berikutnya ke metode APOProcess-nya. Namun, APO kustom dapat mencoba menggunakan APO lagi jika ada panggilan LockForProcess lain nanti, dengan format yang berbeda.
Kompilasi dan penautan
Untuk menggunakan definisi kunci APO CLSID dan properti, sertakan wmcodecdsp.h dan tautkan dengan wmcodecdspuuid.lib. Untuk informasi selengkapnya, lihat header wmcodecdsp.h.
Sampel APO
Ada empat sampel sampel efek sistem audio. Sampel APO tersedia di GitHub di: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO
Panduan umum untuk efek sistem audio kustom
Berikut ini adalah beberapa panduan yang harus diikuti IHV saat menerapkan efek sistem audio kustom API.
- Semua efek sistem audio harus menyediakan opsi hidup/mati. Pengguna tidak boleh dipaksa untuk menggunakan efek sistem audio.
- Interaksi antara fitur di SFX dan MFX APO harus dimediasi oleh API dan UI terkait.
- Fitur yang ditentukan sebagai SFX atau MFX di sini dapat dipindahkan antara SFX dan MFX dalam implementasi kustom. Namun, ini harus dilakukan dengan pemahaman bahwa opsi aktif/nonaktif harus ada dan bahwa aksesibilitas dan kesesuaian opsi tidak boleh disusupi.
- Pelaksana harus ingat bahwa SFX dapat memiliki masker saluran input dan output yang berbeda. MFX APO harus memiliki masker saluran input dan output yang sama.
API yang disediakan Windows
Untuk informasi tentang API lain yang disediakan Windows, lihat topik ini.
Suara yang Ditingkatkan untuk Komputer Laptop
Suara Surround Virtualisasi melalui Headphone
Informasi kustomisasi APO tertentu
Persamaan Kenyaringan (SFX APO)
Persamaan kenyaringan adalah pemrosesan terkompresi (dinamika) yang didorong oleh metrik kenyaringan persepsi. Koreksi Kamar (MFX APO)
Koreksi ruangan menggunakan profil yang dihasilkan Panduan Kalibrasi Ruangan. Profil ini disimpan sebagai blob biner. Format blob saat ini tidak diterbitkan.
Konversi Saluran (SFX APO)
APO Konversi Saluran menangani beberapa tugas.
Virtualisasi Headphone
Efek ini diaktifkan jika format saluran konten yang diputar kembali (N.x) adalah 2.0 atau lebih besar, di mana x bisa 0 atau 1. Masker output harus stereo (0x3). Masker input terbatas pada beberapa kombinasi yang didukung, yang tercantum dalam tabel di bawah ini
Masker Saluran Virtualisasi Headphone
| Nama | Nilai |
|---|---|
| MASK_STEREO MASK_FRONTLR | 0x3 |
| MASK_3_FRONT (SPEAKER_FRONT_CENTER | MASK_FRONTLR) | 0x7 |
| MASK_4_SQUARE (MASK_FRONTLR | MASK_BACKLR) | 0x33 |
| MASK_4_DIAMOND (MASK_FRONTLR | MASK_FBCENTERS) | 0x107 |
| MASK_5_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER) | 0x3F |
| MASK_5_SIDE (MASK_FRONTLR | MASK_SIDELR | SPEAKER_FRONT_CENTER) | 0x60F |
Virtual Surround
Efek ini juga disebut sebagai lipatan kiri /kanan (LTRT) atau pengodean matriks kiri/kanan. Ini digunakan jika format saluran konten yang sedang diputar kembali (N.x) adalah 2,0 atau lebih besar, di mana x bisa 0 atau 1. Lipatan LTRT biasanya 4,0 hingga 2,0. Format input lainnya biasanya ditangani dengan terlebih dahulu menerapkan N.x ke folddown generik 4.0. Namun, dalam implementasi kami, folddown LTRT secara native 5.1 hingga 2.0. Input lain ditangani dengan terlebih dahulu menerapkan N.x ke folddown generik 5.1 terlebih dahulu.
Masker saluran output harus 0x3 (stereo) dan jumlah saluran input—termasuk subwoofer jika ada—tidak boleh lebih dari delapan.
Isi Pembicara
Efek ini digunakan ketika jumlah saluran input (N) kurang dari jumlah saluran output (M). Efeknya mengisi saluran N.x ke saluran M.x, di mana x dapat berupa 0 atau 1.
Masker saluran di Tabel 4—mengabaikan saluran LFE—didukung untuk pengisian speaker. Pengisian speaker mendukung kombinasi kehadiran saluran subwoofer input atau output, sehingga angka di sebelah kiri hanyalah contoh. Konfigurasi aktual mungkin atau mungkin tidak memiliki subwoofer.
Masker Saluran Isian Pembicara
| Nama | Nilai |
|---|---|
| MASK_STEREO MASK_FRONTLR | 0x3 |
| MASK_3_FRONT (SPEAKER_FRONT_CENTER | MASK_FRONTLR) | 0x7 |
| MASK_4_SQUARE (MASK_FRONTLR | MASK_BACKLR) \ | 0x33 |
| MASK_4_DIAMOND (MASK_FRONTLR | MASK_FBCENTERS) | 0x107 |
| MASK_5_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER) | 0x3F |
| MASK_5_SIDE (MASK_FRONTLR | MASK_SIDELR | SPEAKER_FRONT_CENTER) | 0x60F |
| MASK_7_SIDE_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER | MASK_SIDELR) | 0x63F |
| MASK_7_FRONT_SIDE (MASK_FRONTLR | MASK_SIDELR | SPEAKER_FRONT_CENTER | MASK_CENTERLR) | 0x6CF |
| MASK_7_FRONT_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER | MASK_CENTERLR) | 0xFF |
Isi pembicara tidak didukung jika salah satu hal berikut ini benar:
- Masker input sama dengan masker output.
- Satu-satunya perbedaan antara input dan output adalah bahwa satu memiliki saluran kiri/kanan sisi; yang lain memiliki saluran kiri/kanan belakang.
- Input memiliki lebih banyak saluran utama daripada output.
- Masker output mencakup speaker kiri/kanan tengah, tetapi masker input tidak.
- Kumpulan saluran dalam output tetapi tidak dalam input tidak mencakup setidaknya salah satu dari: tengah depan, kiri/kanan belakang, atau kiri/kanan samping.
Ada satu pengecualian untuk item kedua dalam daftar. Jika satu-satunya perbedaan antara input dan output adalah bahwa satu memiliki saluran kiri/kanan sisi dan yang lain memiliki saluran kiri/kanan belakang, isi speaker didukung jika salah satu format berisi saluran yang akan jatuh antara sideLR dan backLR dalam urutan bit masker saluran. Ada tiga saluran seperti itu:
- SPEAKER_FRONT_LEFT_OF_CENTER
- SPEAKER_FRONT_RIGHT_OF_CENTER
- SPEAKER_BACK_CENTER
Jika masker input atau output berisi salah satu dari tiga saluran ini, pengisian speaker mungkin didukung meskipun tidak memenuhi kondisi kedua dalam daftar, tetapi hanya jika kondisi lain terpenuhi. Misalnya, pengisian pembicara dari MASK_7_FRONT_BACK ke atau dari MASK_7_FRONT_SIDE didukung oleh pengisi pembicara karena alasan ini.
Tabel berikut ini memiliki daftar lengkap nilai saluran.
| Nama | Nilai |
|---|---|
| SPEAKER_FRONT_LEFT | 0x1 |
| SPEAKER_FRONT_RIGHT | 0x2 |
| SPEAKER_FRONT_CENTER | 0x4 |
| SPEAKER_LOW_FREQUENCY | 0x8 |
| SPEAKER_BACK_LEFT | 0x10 |
| SPEAKER_BACK_RIGHT | 0x20 |
| SPEAKER_FRONT_LEFT_OF_CENTER | 0x40 |
| SPEAKER_FRONT_RIGHT_OF_CENTER | 0x80 |
| SPEAKER_BACK_CENTER | 0x100 |
| SPEAKER_SIDE_LEFT | 0x200 |
| SPEAKER_SIDE_RIGHT | 0x400 |
Penundaan digunakan untuk saluran dalam konfigurasi output yang "di luar" rentang front-back dalam konfigurasi input. Sebaliknya, jika speaker dalam konfigurasi output "antara" beberapa speaker dalam konfigurasi input dalam arti front-back, output untuk speaker tersebut dihasilkan dengan mencampur beberapa saluran input di kedua sisi saluran output.
pertimbangan Run-Time saat menggunakan kembali API Windows
Bagian ini berisi beberapa informasi tambahan yang mungkin berguna bagi IHV dan OEM saat menerapkan efek sistem audio kustom mereka.
Implementasi APO kustom:
- Menggunakan CoCreateInstance untuk membuat instans atau lebih dari API efek sistem audio kustom Windows.
- Mengonfigurasi setiap instans untuk mengaktifkan serangkaian fitur yang diinginkan.
- Menyisipkan setiap instans ke tempat yang sesuai dalam alur internal APO kustom.
Mengapa satu atau beberapa instans?
Untuk menghindari interaksi yang tidak diinginkan, sebagian besar fitur memerlukan pemesanan relatif tertentu. Karena WINDOWS API menerapkan beberapa fitur di dalam satu APO, beberapa instans APO tersebut mungkin diperlukan untuk memastikan pemesanan yang benar. Misalnya, asumsikan bahwa tiga fitur yang diaktifkan—A, B, dan C—harus diurutkan ABC. Implementasi kustom menangani B tetapi mendelegasikan A dan C ke Windows APO. A dan C kemudian harus dalam instans terpisah dari Microsoft APO sehingga implementasi kustom B dapat terjadi di antara mereka.
Windows mengimplementasikan koreksi ruangan di MFX APO, yang berarti merupakan objek COM terpisah dari SFX APO. Implementasi kustom dapat memilih untuk mendelegasikan koreksi ruang ke implementasi Windows tetapi menempatkannya di APO SFX kustom. Implementasi SFX kustom kemudian mungkin perlu mendelegasikan beberapa pemrosesan ke implementasi Windows SFX APO dan pemrosesan lainnya ke implementasi Windows MFX APO.
Menangani batasan kombinasi format input-output yang berbeda
Banyak fitur—terutama manajemen bass—tidak berfungsi dalam kasus tertentu. Misalnya, manajemen bass penerusan tidak terdefinisi jika properti konfigurasi speaker bass adalah "AllSmall" atau "AllLarge" dan format output tidak menyertakan saluran subwoofer atau bendera NoSub diatur. Tidak selalu mungkin untuk mendeteksi kegagalan selama panggilan IPropertyStore::SetValue . Metode ini mencoba mengaktifkan fitur, tetapi format input dan output tidak diketahui pada saat itu karena LockForProcess harus terjadi setelah semua manipulasi properti. Ini berarti bahwa dimungkinkan untuk mengaktifkan fitur, melihatnya tampaknya berhasil, tetapi tidak memiliki pemrosesan yang sesuai berlangsung.
Dua strategi tersedia untuk menangani situasi seperti itu:
- Pelajari dengan cermat bagian khusus fitur dari dokumen ini untuk dapat memprediksi dengan tepat kapan fitur tertentu akan atau tidak akan berhasil.
- Panggil IPropertyStore::GetValue setelah LockForProcess dipanggil untuk memeriksa status properti penting.
Saat LockForProcess menentukan bahwa fitur tertentu tidak dapat diaktifkan—karena format input dan output atau nilai beberapa properti lain—LockForProcess memperbarui nilai properti yang sesuai di penyimpanan properti.
Interaksi antara Pengisi pembicara dan Manajemen Bass
Saat pengisian speaker menyala dan subwoofer tersambung, manajemen bass penerusan harus terjadi sebelum pengisian speaker untuk menghindari pemfilteran sisir sinyal frekuensi rendah oleh penundaan surround pengisian speaker.
Ketika pengisian speaker diaktifkan dan tidak ada subwoofer yang terhubung, dua jenis manajemen bass maju dimungkinkan:
- Jika speaker kiri/kanan depan besar, manajemen bass ke depan merutekan bagian frekuensi rendah dari saluran surround dan tengah ke speaker kiri/kanan depan. Manajemen bass maju harus datang setelah pembicara mengisi kasus ini.
- Jika semua speaker kecil, manajemen bass ke depan menjadi perlindungan frekuensi rendah untuk semua speaker utama.
Ini dapat terjadi baik sebelum atau sesudah pengisian pembicara. Namun, karena alasan performa, lebih baik memiliki manajemen bass ke depan sebelum pengisian pembicara.
Windows APO menerapkan konfigurasi pengisian speaker umum tertentu, seperti 2.0 => 5.1, dengan kode khusus yang dioptimalkan yang menangani manajemen bass terbalik dalam langkah yang sama dengan pengisian pembicara.
Interaksi antara Folddown dan Manajemen Bass
Virtualisasi headphone hanya mendukung manajemen bass terbalik:
- Manajemen bass maju tidak masuk akal dengan virtualisasi headphone.
- Untuk kesederhanaan implementasi, perlindungan frekuensi rendah dan peningkatan bass tidak didukung.
Ketika salah satu virtualisasi headphone, pengodean surround virtual, atau efek pengisian speaker aktif, manajemen bass terbalik ditangani selama langkah tersebut. Manajemen bass terbalik masih dikontrol melalui properti manajemen bass terbalik API seolah-olah itu adalah fitur terpisah. Dalam kasus ini, manajemen bass terbalik hanya mengontrol koefisien lipatan untuk saluran input .1. Salah satu masalah terbuka adalah bahwa manajemen bass terbalik tidak dapat dinonaktifkan saat LTRT aktif. Dalam hal ini, manajemen bass terbalik menggunakan perolehan saluran subwoofer yang tidak konsisten.
EFEK sistem audio Windows API menerapkan beberapa pemrosesan kecil—keuntungan dan penundaan—bahkan ketika tidak ada fitur yang diaktifkan. Tujuan dari pemrosesan tersebut adalah untuk memastikan bahwa parameter penguatan dan penundaan tidak berubah ketika fitur diaktifkan dengan cepat. Alasannya adalah bahwa penundaan melekat pada implementasi beberapa fitur, dan keuntungan <1 diterapkan oleh beberapa fitur untuk menghindari output yang terlalu tinggi dalam situasi tertentu. Kumpulan fitur yang tersedia tergantung pada format input-output dan properti tertentu, dan begitu juga perolehan dan penundaan normalisasi kumulatif.
Jika fitur tidak akan diaktifkan atau dinonaktifkan dengan cepat, perolehan normalisasi dapat dinonaktifkan dengan mengatur MFPKEY_CORR_NORMALIZATION_GAIN properti ke FALSE dengan memanggil IPropertyStore::SetValue. Properti mungkin TRUE secara default.
Tidak ada mekanisme untuk menonaktifkan penundaan normalisasi karena dianggap lebih kecil kemungkinannya untuk tidak keberatan daripada perolehan normalisasi. Jika penundaan normalisasi tidak disarankan, cukup lewati APO yang dimaksud.