Pemrosesan Audio Hardware-Offloaded
Pemrosesan audio yang dibongkar perangkat keras memungkinkan tugas pemrosesan audio utama dilakukan di luar CPU utama komputer.
Pemrosesan audio bisa sangat intensif secara komputasi. Jadi dalam banyak skenario, mungkin bermanfaat untuk memungkinkan prosesor khusus mengurus tugas pemrosesan seperti, misalnya, mencampur, dan menerapkan efek.
Ketika Anda mengimplementasikan driver untuk audio offload, Anda mengembangkan driver yang dapat memproses aliran audio yang dibongkar, dan untuk mengekspos kemampuan tersebut ke sistem audio Windows.
Topik berikut di bagian ini membahas pengembangan driver, dampak aplikasi, dan masalah lain yang harus Anda ketahui ketika Anda mengembangkan driver audio untuk adaptor audio yang mengimplementasikan mesin audio perangkat keras untuk menangani aliran audio yang tidak dimuat.
Implementasi Driver Audio Yang Dibongkar Perangkat Keras
Antarmuka Pembantu untuk Pemrosesan Audio Yang Dibongkar
Pelaporan Glitch untuk Audio Yang Dibongkar
Untuk informasi tentang API yang dibongkar, lihat Efek APO Yang Dibongkar Perangkat Keras
Gambaran Umum Arsitektur Pemrosesan Audio Hardware-Offloaded
Mesin audio perangkat lunak
Diagram berikut menunjukkan mesin audio perangkat lunak Windows.
Aliran audio tiba di mesin audio perangkat lunak dari lapisan API sesi audio Windows (WASAPI), dan mungkin melalui API tingkat yang lebih tinggi seperti Media Foundation. Dalam efek aliran mesin audio perangkat lunak (SFX), dapat diterapkan per aliran sebelum aliran terpisah dicampur, dan kemudian melewati efek titik akhir yang tersedia (EFX) dan dikirim ke perangkat keras dan speaker penyajian.
Mesin audio perangkat keras
Mesin audio perangkat keras diimplementasikan dalam adaptor audio, dan sebagian besar mencerminkan fungsionalitas mesin audio perangkat lunak. Dan meskipun Windows mendukung pemrosesan audio yang dilepas perangkat keras, driver audio untuk adaptor audio tertentu bertanggung jawab untuk mengekspos kemampuan perangkat keras audio yang mendasar, menggunakan topologi yang ditunjukkan dalam diagram berikut.
Mesin audio perangkat keras harus menerima aliran proses host tunggal dan hingga n aliran yang dibongkar. Aliran yang dilepaskan ini dirutekan langsung dari lapisan aplikasi untuk diproses dalam perangkat keras. Dengan kata lain, aliran yang dibongkar tidak akan diteruskan melalui mesin audio perangkat lunak. Diagram menunjukkan implementasi yang dirancang untuk menangani hingga tiga aliran yang dilepas. Aliran proses host adalah output akhir dari mixer perangkat lunak dari semua aliran yang diproses di mesin audio perangkat lunak. Setiap mesin audio perangkat keras juga harus berisi mixer perangkat keras.
Untuk mempertahankan paritas dengan mesin audio perangkat lunak dan antarmuka WASAPI, mesin audio perangkat keras perlu menyediakan aliran output audio akhir kembali ke tumpukan audio dalam bentuk aliran loopback. Ini sangat penting untuk aplikasi dan skenario yang mengandalkan Pembatalan Echo Akustik, yang membutuhkan pengetahuan tentang aliran output akhir untuk membatalkan gema dan mencegah umpan balik.
Untuk mengimplementasikan jalur untuk aliran loopback, driver audio bertanggung jawab untuk mengekspos pin loopback. Pin ini akan mengembalikan data audio dari output mesin audio akhir, jika data dikodekan ke format PCM. Jika tidak, hasil pasca-pencampuran (tetapi pra-pengodean) akan dikembalikan. Ini berarti bahwa dalam kasus data audio yang diproses dengan EFX perangkat keras yang mengodekan ke format non-PCM, aliran loopback diambil langsung setelah mixer perangkat keras, sebelum tahap EFX di mesin audio perangkat keras. Untuk informasi tentang topologi filter KS yang mewakili mesin audio perangkat keras, lihat Implementasi Driver Audio Offloaded Perangkat Keras.
Arsitektur audio terintegrasi
Diagram berikut menunjukkan gambaran umum arsitektur yang dihasilkan ketika mesin audio perangkat keras bekerja dengan mesin audio perangkat lunak Windows.
Dalam skenario di mana driver audio telah menunjukkan dukungannya untuk pemrosesan audio yang dibongkar, n pertama (dalam hal ini, tiga) aliran yang diinisialisasi akan dirutekan langsung dari lapisan WASAPI ke mesin audio perangkat keras, melewati mesin audio perangkat lunak. Setiap aliran audio baru berikutnya ke n yang didukung oleh mesin audio perangkat keras akan dirutekan melalui mesin audio perangkat lunak untuk diproses. Aliran yang dihasilkan dari mesin audio perangkat lunak kemudian dikirim ke mesin audio perangkat keras sebagai aliran proses host. Aliran proses host dicampur dengan aliran n pertama, pemrosesan EFX diterapkan, dan aliran yang dihasilkan kemudian dikirim ke speaker.
Topologi Filter KS
Dalam sistem operasi Windows 8 dan yang lebih baru, dukungan telah disediakan untuk mesin audio perangkat keras on-board untuk memproses aliran audio. Ketika Anda mengembangkan adaptor audio seperti itu, driver audio terkait harus mengekspos fakta ini ke sistem audio mode pengguna dengan cara tertentu, sehingga sistem audio dapat menemukan, menggunakan, dan mengekspos fitur adaptor ini dengan benar dan drivernya.
Untuk memungkinkan driver audio mengekspos kemampuan perangkat keras adaptor audio baru ini, Windows 8 memperkenalkan topologi filter KS yang harus digunakan driver:
Seperti yang ditunjukkan pada gambar sebelumnya, topologi filter KS mewakili jalur data melalui perangkat keras, dan juga menunjukkan fungsi yang tersedia di jalur tersebut. Dalam kasus adaptor audio yang dapat memproses audio yang dibongkar, ada input dan output berikut (disebut pin) pada filter KS:
Satu pin Proses Host. Ini mewakili input ke dalam filter KS dari mesin audio perangkat lunak.
Satu pin Loopback. Ini mewakili output dari mesin audio perangkat keras ke lapisan API sesi audio Windows (WASAPI).
Sejumlah pin Offloaded-audio. Meskipun gambar hanya menunjukkan satu pin jenis ini, IHV bebas untuk mengimplementasikan nomor (n) pin apa pun.
Layanan aktual dalam sistem audio mode pengguna yang "mengarah" ke penemuan adaptor audio dan drivernya, adalah AudioEndpointBuilder. Layanan AudioEndpointBuilder memantau kelas KSCATEGORY_AUDIO untuk kedatangan dan penghapusan antarmuka perangkat. Saat driver perangkat audio mendaftarkan instans baru dari kelas antarmuka perangkat KSCATEGORY_AUDIO , pemberitahuan kedatangan antarmuka perangkat dimatikan. Layanan AudioEndpointBuilder mendeteksi pemberitahuan kedatangan antarmuka perangkat dan menggunakan algoritma untuk memeriksa topologi perangkat audio dalam sistem sehingga dapat mengambil tindakan yang tepat.
Saat Anda mengembangkan driver audio untuk mendukung adaptor yang mampu memproses offloaded-audio, driver Anda harus menggunakan titik akhir audio KSNODETYPE_AUDIO_ENGINE untuk mengekspos kemampuan mesin audio perangkat keras. Untuk informasi selengkapnya tentang proses penemuan titik akhir audio, lihat Algoritma Penyusun Titik Akhir Audio.
Pertimbangan Antarmuka Pengguna
Anda mengembangkan driver audio untuk mengontrol kemampuan perangkat keras yang mendasar dari adaptor audio yang mampu memproses offloaded-audio. Ini berarti bahwa driver Anda memiliki pengetahuan terbaik tentang cara mengontrol fitur adaptor. Jadi Anda harus mengembangkan UI yang akan mengekspos fitur adaptor kepada pengguna akhir dalam bentuk opsi yang dapat mereka pilih, aktifkan, dan/atau nonaktifkan.
Namun, jika Anda sudah memiliki UI yang digunakan untuk mengontrol objek pemrosesan audio (API) yang Anda kembangkan, UI ini dapat diperluas untuk bekerja dengan adaptor audio baru Anda. Dalam hal ini, ekstensi Anda ke UI akan menyediakan kontrol perangkat lunak untuk API, dan kontrol perangkat keras untuk adaptor.
Dampak Aplikasi
Fungsionalitas yang dijelaskan untuk jenis adaptor audio baru ini dan driver terkaitnya, dapat digunakan oleh aplikasi UWP melalui WASAPI, Media Foundation, Media Engine, atau tag audio> HTML 5<. Perhatikan bahwa Wave dan DSound tidak dapat digunakan, karena tidak tersedia untuk aplikasi UWP. Perhatikan juga bahwa aplikasi Desktop tidak dapat menggunakan kemampuan offloading adaptor audio yang mendukung audio yang dibongkar perangkat keras. Aplikasi ini masih dapat merender audio, tetapi hanya melalui pin host yang memanfaatkan mesin audio perangkat lunak.
Jika aplikasi UWP mengalirkan konten media dan menggunakan tag audio> Media Foundation, Media Engine, atau HTML 5<, aplikasi secara otomatis ikut serta untuk offloading perangkat keras selama kategori audio yang tepat telah diatur untuk streaming. Memilih ikut serta untuk offloading perangkat keras dilakukan berdasarkan per aliran.
Aplikasi UWP yang menggunakan WASAPI atau komunikasi streaming harus secara eksplisit ikut serta untuk offloading perangkat keras.