Bagikan melalui

Aktivasi Suara

Nota

Artikel ini terutama mengacu pada pengalaman konsumen yang dikirimkan di Windows 10 (versi 1909 dan yang lebih lama). Untuk informasi selengkapnya, lihat Akhir dukungan untuk Cortana.

Cortana, platform ucapan Windows, mendukung semua pengalaman ucapan di Windows 10, seperti Cortana dan dikte. Aktivasi suara adalah fitur yang memungkinkan pengguna memanggil mesin pengenalan ucapan dari berbagai status daya perangkat dengan mengucapkan frasa tertentu—"Hey Cortana." Untuk membuat perangkat keras yang mendukung teknologi aktivasi suara, tinjau informasi dalam artikel ini.

Nota

Menerapkan aktivasi suara adalah proyek yang signifikan dan merupakan tugas yang diselesaikan oleh vendor SoC. OEM dapat menghubungi vendor SoC mereka untuk informasi tentang implementasi SoC aktivasi suara mereka.

Pengalaman Pengguna Akhir Cortana

Untuk memahami pengalaman interaksi suara yang tersedia di Windows, tinjau artikel ini.

Article Deskripsi
Apa itu Cortana? Memberikan gambaran umum dan arah penggunaan untuk Cortana

Pengantar Aktivasi Suara "Hey Cortana" dan "Pelajari suara saya"

Aktivasi Suara Hey Cortana"

Fitur Aktivasi Suara (VA) "Hey Cortana" memungkinkan pengguna untuk dengan cepat melibatkan pengalaman Cortana di luar konteks aktif mereka (yaitu, apa yang saat ini ada di layar) dengan menggunakan suara mereka. Pengguna sering ingin dapat langsung mengakses pengalaman tanpa harus berinteraksi atau menyentuh perangkat secara fisik. Pengguna telepon mungkin mengemudi di mobil sambil memperhatikan dan mengoperasikan kendaraan. Pengguna Xbox mungkin tidak ingin menemukan dan menyambungkan pengontrol. Pengguna PC mungkin menginginkan akses cepat ke pengalaman tanpa harus melakukan beberapa tindakan mouse, sentuhan, atau keyboard. Misalnya, komputer di dapur digunakan saat memasak.

Aktivasi suara menyediakan input ucapan yang secara kontinu mendengarkan melalui frasa kunci atau frasa aktivasi yang telah ditentukan sebelumnya. Frasa kunci dapat diucapkan secara mandiri ("Hey Cortana") sebagai perintah berjenjang, atau diikuti dengan tindakan ucapan, misalnya, "Hey Cortana, di mana pertemuan saya berikutnya?", perintah berantai.

Istilah Deteksi Kata Kunci menjelaskan deteksi kata kunci oleh perangkat keras atau perangkat lunak.

Kata kunci hanya aktivasi terjadi ketika hanya kata kunci Cortana yang dikatakan, Cortana memulai dan memutar suara EarCon untuk menunjukkan bahwa ia telah memasuki mode mendengarkan.

Perintah berantai menjelaskan kemampuan mengeluarkan perintah segera mengikuti kata kunci (seperti "Hey Cortana, panggil John") dan minta Cortana memulai (jika belum dimulai) dan mengikuti perintah (memulai panggilan telepon dengan John).

Diagram ini mengilustrasikan aktivasi berantai dan aktivasi hanya dengan kata kunci.

Diagram memperlihatkan perbedaan antara aktivasi berantai dan khusus kata kunci dengan buffer audio dan urutan waktu.

Microsoft menyediakan spotter kata kunci default OS (spotter kata kunci perangkat lunak) yang digunakan untuk memastikan kualitas deteksi kata kunci perangkat keras dan untuk memberikan pengalaman Hey Cortana jika deteksi kata kunci perangkat keras tidak ada atau tidak tersedia.

Fitur "Pelajari suara saya"

Fitur "Pelajari suara saya" memungkinkan pengguna untuk melatih Cortana mengenali suara unik mereka. Ini dicapai oleh pengguna yang memilih Pelajari bagaimana saya mengatakan "Hey Cortana" di layar pengaturan Cortana. Pengguna kemudian mengulangi enam frasa yang dipilih dengan hati-hati yang menyediakan berbagai pola fonetik yang memadai untuk mengidentifikasi atribut unik suara pengguna.

Tangkap layar pengaturan desktop Cortana untuk pengenalan kata kunci perangkat keras dan fitur aktif saat suara.

Saat aktivasi suara dipasangkan dengan "Pelajari suara saya", kedua algoritma bekerja sama untuk mengurangi aktivasi palsu. Ini sangat berharga untuk skenario ruang rapat, di mana satu orang mengatakan "Hey Cortana" di ruangan yang penuh dengan perangkat. Fitur ini hanya tersedia untuk Windows 10 versi 1903 dan yang lebih lama.

Aktivasi suara didukung oleh spotter kata kunci (KWS) yang bereaksi jika frasa kunci terdeteksi. Jika KWS membangunkan perangkat dari status bertenaga rendah, solusinya dikenal sebagai Wake on Voice (WoV). Untuk informasi selengkapnya, lihat Bangun dengan Suara.

Glosarium Ketentuan

Glosarium ini meringkas istilah yang terkait dengan aktivasi suara.

Istilah Contoh/definisi
Perintah Bertahap Contoh: Hey Cortana <jeda, tunggu suara EarCon berbunyi> Apa cuacanya? Ini terkadang disebut sebagai "Perintah dua kali tembak" atau "Hanya kata kunci"
Perintah Berantai Contoh: Hey Cortana bagaimana cuacanya? Ini kadang-kadang disebut sebagai "Perintah sekali jalan"
Aktivasi Suara Skenario menyediakan deteksi kata kunci dari frasa kunci aktivasi yang telah ditentukan sebelumnya. Misalnya, "Hey Cortana" adalah skenario Aktivasi Suara Microsoft.
WoV Wake-on-Voice – Teknologi yang memungkinkan Aktivasi Suara dari layar mati, status daya yang lebih rendah, ke layar pada status daya penuh.
WoV dari Siaga Modern Wake-on-Voice dari status layar mati Standby Modern (S0ix) ke status layar menyala dengan daya penuh (S0).
Siaga Modern Infrastruktur Windows Low Power Idle - penerus dari Connected Standby (CS) di Windows 10. Status pertama siaga modern adalah ketika layar mati. Status tidur terdalam adalah ketika berada di DRIPS/Ketahanan. Untuk informasi selengkapnya, lihat Siaga Modern
KWS Pendeteksi kata kunci - algoritma yang mendeteksi "Hey Cortana"
SW KWS Spotter kata kunci perangkat lunak - implementasi KWS yang berjalan pada host (CPU). Untuk "Hey Cortana," SW KWS disertakan sebagai bagian dari Windows.
HW KWS Spotter kata kunci dengan dukungan perangkat keras – implementasi KWS yang berjalan dengan proses dialihkan ke perangkat keras.
Penyangga Ledakan Buffer melingkar yang digunakan untuk menyimpan data PCM dan dapat meledak secara tiba-tiba ketika terjadi deteksi KWS, sehingga semua audio yang memicu deteksi KWS dapat disertakan.
Adaptor OEM Pendeteksi Kata Kunci Shim tingkat driver yang memungkinkan perangkat keras berkemampuan WoV untuk berkomunikasi dengan Windows dan sistem Cortana.
Model File data model akustik yang digunakan oleh algoritma KWS. File data tersebut bersifat statis. Model dilokalkan, satu per lokalitas.

Mengintegrasikan Pendeteksi Kata Kunci Perangkat Keras

Untuk menerapkan spotter kata kunci perangkat keras (HW KWS), selesaikan tugas berikut.

Persyaratan WoV untuk pelacak kata kunci yang dilakukan oleh perangkat keras (HW KWS)

  • HW KWS WoV didukung selama mode S0 Working dan mode S0 sleep, yang juga dikenal sebagai Mode Siaga Modern.
  • HW KWS WoV tidak didukung oleh S3.

Persyaratan AEC untuk HW KWS

  • Untuk Windows Versi 1709

    • Untuk mendukung perangkat keras KWS WoV untuk status tidur S0 (Siaga Modern), AEC tidak diperlukan.
    • HW KWS WoV untuk status kerja S0 tidak didukung di Windows Versi 1709.

  • Untuk Windows Versi 1803

    • HW KWS WoV untuk status kerja S0 didukung.
    • Untuk mengaktifkan HW KWS WoV untuk status kerja S0, APO harus mendukung AEC.

Gambaran Umum Kode Sampel

Ada kode sampel untuk driver audio yang mengimplementasikan aktivasi suara di GitHub sebagai bagian dari sampel adaptor audio virtual SYSVAD. Disarankan untuk menggunakan kode ini sebagai titik awal. Kode tersedia di lokasi ini.

https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/

Untuk informasi selengkapnya tentang driver audio sampel SYSVAD, lihat Contoh Driver Audio.

Informasi Sistem Pengenalan Kata Kunci

Dukungan Tumpukan Audio Aktivasi Suara

Antarmuka eksternal pada stack audio untuk mengaktifkan aktivasi suara berfungsi sebagai alur komunikasi untuk platform suara dan pengandar audio. Antarmuka eksternal dibagi menjadi tiga bagian.

  • Antarmuka Pengandar Perangkat Pendeteksi Kata Kunci (DDI). Antarmuka Driver Perangkat Pendeteksi Kata Kunci bertanggung jawab untuk mengonfigurasi dan mengaktifkan HW Keyword Spotter (KWS). Ini juga digunakan oleh driver untuk memberi tahu sistem peristiwa deteksi.
  • OEM Adaptor DLL Pendeteksi Kata Kunci. DLL ini mengimplementasikan antarmuka COM untuk menyesuaikan data buram khusus driver untuk digunakan oleh OS untuk membantu deteksi kata kunci.
  • Peningkatan WaveRT streaming. Penyempurnaan memungkinkan driver audio untuk mentransmisikan data audio yang di-buffer secara semburan dari deteksi kata kunci.

Properti Titik Akhir Audio

Pembangunan grafik titik akhir audio terjadi secara normal. Grafik disiapkan untuk menangani penangkapan waktu nyata dengan lebih cepat. Tanda waktu pada buffer yang diambil tetap benar. Secara khusus, tanda waktu mencerminkan data dengan benar yang diambil di masa lalu dan di-buffer, dan sekarang meledak.

Teori bypass streaming audio Bluetooth

Driver mengekspos filter KS untuk perangkat penangkap sinyalnya seperti biasa. Filter ini mendukung beberapa properti KS dan peristiwa KS untuk mengonfigurasi, mengaktifkan, dan memberi sinyal peristiwa deteksi. Filter ini juga menyertakan pabrik pin lain yang diidentifikasi sebagai pin spotter kata kunci (KWS). Pin ini digunakan untuk mengalirkan audio dari pendeteksi kata kunci.

Propertinya adalah:

  • Jenis kata kunci yang didukung - KSPROPERTY_SOUNDDETECTOR_PATTERNS. Sistem operasi mengatur properti ini untuk mengonfigurasi kata kunci yang akan terdeteksi.
  • Daftar GUID untuk pola kata kunci - KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. Properti ini digunakan untuk mendapatkan daftar GUID yang mengidentifikasi jenis pola yang didukung.
  • Bersenjata - KSPROPERTY_SOUNDDETECTOR_ARMED. Properti baca/tulis ini adalah status boolean yang menunjukkan apakah detektor bersenjata. OS mengatur ini untuk melibatkan detektor kata kunci. Sistem operasi dapat menghapus ini untuk menonaktifkan. Driver secara otomatis menghapus ini ketika pola kata kunci diatur dan juga setelah kata kunci terdeteksi. (OS harus diatur ulang.)
  • Cocokkan hasil - KSPROPERTY_SOUNDDETECTOR_MATCHRESULT. Properti baca ini menyimpan data hasil setelah deteksi terjadi.

Peristiwa yang diaktifkan saat kata kunci terdeteksi adalah peristiwa KSEVENT_SOUNDDETECTOR_MATCHDETECTED .

Urutan Operasi

Mulai sistem

  1. OS membaca jenis kata kunci yang didukung untuk memverifikasi bahwa OS memiliki kata kunci dalam format tersebut.
  2. OS mengawasi peristiwa perubahan status detektor.
  3. OS mengatur pola kata kunci.
  4. OS mengaktifkan detektor.

Saat Menerima Acara KS

  1. Pengemudi mematikan detektor.
  2. OS membaca status detektor kata kunci, mengurai data yang dikembalikan, dan menentukan pola mana yang terdeteksi.
  3. OS mengaktifkan ulang detektor.

Pengandar Internal dan Operasi Perangkat Keras

Saat detektor diaktifkan, perangkat keras dapat terus menangkap dan menyangga data audio dalam buffer FIFO kecil. (Ukuran buffer FIFO ini ditentukan oleh persyaratan di luar dokumen ini, tetapi biasanya mungkin ratusan milidetik hingga beberapa detik.) Algoritma deteksi beroperasi pada streaming data melalui buffer ini. Desain driver dan perangkat keras sedemikian rupa sehingga sebagai persiapan, tidak ada interaksi antara driver dan perangkat keras, dan tidak ada interupsi ke prosesor aplikasi sampai kata kunci terdeteksi. Ini memungkinkan sistem untuk mencapai status daya yang lebih rendah jika tidak ada aktivitas lain.

Ketika perangkat keras mendeteksi kata kunci, itu akan menghasilkan gangguan. Saat menunggu driver melayani gangguan, perangkat keras terus mengambil audio ke dalam buffer, memastikan tidak ada data setelah kata kunci hilang, dalam batas buffering.

Tanda Waktu Kata Kunci

Setelah mendeteksi kata kunci, semua solusi aktivasi suara harus menyimpan semua kata kunci yang diucapkan, termasuk 250ms sebelum kata kunci dimulai. Driver audio harus menyediakan tanda waktu yang mengidentifikasi awal dan akhir frasa kunci di aliran.

Untuk mendukung tanda waktu mulai/akhir kata kunci, perangkat lunak DSP mungkin perlu memberi tanda waktu peristiwa secara internal berdasarkan jam DSP. Setelah kata kunci terdeteksi, perangkat lunak DSP berinteraksi dengan driver untuk menyiapkan peristiwa KS. Driver dan perangkat lunak DSP perlu memetakan tanda waktu DSP ke nilai penghitung kinerja Windows. Metode melakukan ini khusus untuk desain perangkat keras. Salah satu solusi yang mungkin adalah bagi driver untuk membaca penghitung kinerja saat ini, mengkueri tanda waktu DSP saat ini, membaca penghitung kinerja saat ini lagi, lalu memperkirakan korelasi antara penghitung kinerja dan waktu DSP. Kemudian mengingat korelasi, driver dapat memetakan tanda waktu DSP kata kunci ke tanda waktu penghitung kinerja Windows.

Antarmuka Adaptor OEM untuk Pendeteksi Kata Kunci

OEM menyediakan implementasi objek COM yang bertindak sebagai perantara antara OS dan driver, membantu menghitung atau mengurai data buram yang ditulis dan dibaca ke driver audio melalui KSPROPERTY_SOUNDDETECTOR_PATTERNS dan KSPROPERTY_SOUNDDETECTOR_MATCHRESULT.

CLSID dari objek COM adalah GUID jenis pola detektor yang dikembalikan oleh KSPROPERTY_SOUNDDETECTOR_SUPPORTEDPATTERNS. OS memanggil CoCreateInstance dengan melewatkan GUID jenis pola untuk menginstansiasi objek COM yang sesuai dan kompatibel dengan jenis pola kata kunci serta memanggil metode pada antarmuka IKeywordDetectorOemAdapter dari objek tersebut.

Persyaratan Com Threading Model

Implementasi OEM dapat memilih salah satu model utas COM.

IKeywordDetectorOemAdapter

Desain antarmuka mencoba menjaga implementasi objek tetap stateless. Dengan kata lain, implementasi tidak boleh memerlukan status untuk disimpan di antara panggilan metode. Bahkan, kelas C++ internal kemungkinan tidak memerlukan variabel anggota apa pun di luar yang diperlukan untuk menerapkan objek COM secara umum.

Metode

Terapkan metode berikut.

KATA KUNCIID

Enumerasi KEYWORDID mengidentifikasi teks/fungsi frasa kata kunci dan juga digunakan dalam adaptor Windows Biometric Service. Untuk informasi selengkapnya, lihat Gambaran Umum Kerangka Kerja Biometrik - Komponen Platform Inti

typedef enum  {
  KwInvalid    = 0,
  KwHeyCortana = 1,
  KwSelect     = 2
} KEYWORDID;

PEMILIH KATA KUNCI

Struktur KEYWORDSELECTOR adalah sekumpulan ID yang secara unik memilih kata kunci dan bahasa tertentu.

typedef struct
{
    KEYWORDID KeywordId;
    LANGID LangId;
} KEYWORDSELECTOR;

Menangani Data Model

Model independen pengguna statis - DLL OEM biasanya akan menyertakan beberapa data model independen pengguna statis baik yang disertakan dalam DLL atau dalam file data terpisah yang disertakan dengan DLL. Kumpulan ID kata kunci yang didukung yang dikembalikan oleh rutinitas GetCapabilities akan bergantung pada data ini. Misalnya, jika daftar ID kata kunci yang didukung yang dikembalikan oleh GetCapabilities mencakup KwHeyCortana, data model independen pengguna statis akan menyertakan data untuk "Hey Cortana" (atau terjemahannya) untuk semua bahasa yang didukung.

Model dependen pengguna dinamis - IStream menyediakan model penyimpanan akses acak. OS meneruskan penunjuk antarmuka IStream ke banyak metode pada antarmuka IKeywordDetectorOemAdapter. OS mendukung implementasi IStream dengan penyimpanan yang sesuai hingga 1MB data.

Konten dan struktur data dalam penyimpanan ini ditentukan oleh OEM. Tujuan yang dimaksudkan adalah untuk penyimpanan persisten data model dependen pengguna yang dihitung atau diambil oleh DLL OEM.

Sistem Operasi dapat memanggil metode antarmuka dengan IStream kosong, terutama jika pengguna belum pernah melatih kata kunci. OS membuat penyimpanan IStream terpisah untuk setiap pengguna. Dengan kata lain, IStream tertentu menyimpan data model untuk satu dan hanya satu pengguna.

Pengembang DLL OEM memutuskan cara mengelola data independen pengguna dan dependen pengguna. Namun, itu tidak akan pernah menyimpan data pengguna di mana pun di luar IStream. Salah satu kemungkinan desain DLL OEM akan beralih secara internal antara mengakses IStream dan data independen pengguna statis tergantung pada parameter metode saat ini. Desain alternatif mungkin memeriksa IStream pada awal setiap panggilan metode dan menambahkan data pengguna independen statis ke IStream jika data tersebut belum ada, yang memungkinkan sisa metode hanya mengakses IStream untuk semua data model.

Pelatihan dan Pengoperasian Pemrosesan Audio

Seperti yang dijelaskan sebelumnya, alur UI pelatihan menghasilkan kalimat lengkap yang kaya secara fonetik tersedia di aliran audio. Setiap kalimat diteruskan secara individual ke IKeywordDetectorOemAdapter::VerifyUserKeyword untuk memverifikasinya berisi kata kunci yang diharapkan dan memiliki kualitas yang dapat diterima. Setelah semua kalimat dikumpulkan dan diverifikasi oleh UI, semuanya diteruskan dalam satu panggilan ke IKeywordDetectorOemAdapter::ComputeAndAddUserModelData.

Audio diproses dengan cara unik untuk pelatihan aktivasi suara. Tabel berikut ini meringkas perbedaan antara pelatihan aktivasi suara dan penggunaan pengenalan suara reguler.

Pelatihan Suara Pengenalan Suara
Mode Mentah Mentah atau Pidato
pin Biasa KWS
Audio Format Float 32-bit (Tipe = Audio, Subjenis = IEEE_FLOAT, Laju Pengambilan Sampel = 16 kHz, bit = 32) Dikelola oleh lapisan audio sistem operasi
Mic Mikrofon 0 Semua mikrofon dalam susunan, atau mono

Gambaran Umum Sistem Pengenalan Kata Kunci

Diagram ini memberikan gambaran umum tentang sistem pengenalan kata kunci.

Diagram sistem pengenalan kata kunci termasuk Cortana, runtime pengenalan suara, dan manajer aktivasi suara, serta komponen lainnya.

Diagram Urutan Pengenalan Kata Kunci

Dalam diagram ini, modul pengoperasian ucapan ditampilkan sebagai platform ucapan. Seperti disebutkan sebelumnya, platform ucapan Windows digunakan untuk mendukung semua pengalaman ucapan di Windows 10 seperti Cortana dan dikte.

Selama startup, kemampuan dikumpulkan menggunakan IKeywordDetectorOemAdapter::GetCapabilities.

Diagram urutan pengenalan kata kunci selama startup, memperlihatkan pelatihan UX, platform ucapan, dan detektor kata kunci OEM.

Kemudian ketika pengguna memilih untuk "Pelajari suara saya", alur pelatihan dipanggil.

Diagram urutan pengenalan kata kunci selama proses 'Pelajari suara saya', memperlihatkan pelatihan UX, platform ucapan, dan detektor kata kunci OEM.

Diagram ini menjelaskan proses persiapan deteksi kata kunci.

Diagram urutan pengenalan kata kunci selama persiapan deteksi kata kunci, menunjukkan platform pengenalan ucapan, detektor kata kunci OEM, dan detektor driver audio.

Peningkatan WAVERT

Antarmuka miniport didefinisikan untuk diimplementasikan oleh driver miniport WaveRT. Antarmuka ini menyediakan metode untuk menyederhanakan driver audio, meningkatkan performa dan keandalan alur audio OS, atau mendukung skenario baru. Properti antarmuka perangkat PnP baru didefinisikan yang memungkinkan driver untuk memberikan ekspresi statis dari batasan ukuran buffernya ke OS.

Ukuran Buffer

Driver beroperasi di bawah berbagai batasan saat memindahkan data audio antara OS, driver, dan perangkat keras. Batasan ini mungkin disebabkan oleh transportasi perangkat keras fisik yang memindahkan data antara memori dan perangkat keras, dan/atau karena modul pemrosesan sinyal dalam perangkat keras atau DSP terkait.

solusi HW-KWS harus mendukung ukuran pengambilan audio setidaknya 100ms dan hingga 200ms.

Driver mengekspresikan batasan ukuran buffer dengan mengatur properti perangkat DEVPKEY_KsAudio_PacketSize_Constraints pada antarmuka perangkat PnP KSCATEGORY_AUDIO filter KS yang memiliki pin streaming KS. Properti ini harus tetap valid dan stabil saat antarmuka filter KS diaktifkan. OS dapat membaca nilai ini kapan saja tanpa harus membuka handle ke driver dan memanggil driver.

DEVPKEY_KsAudio_PacketSize_Constraints

Nilai properti DEVPKEY_KsAudio_PacketSize_Constraints berisi struktur KSAUDIO_PACKETSIZE_CONSTRAINTS yang menjelaskan batasan perangkat keras fisik (yaitu, karena mekanisme mentransfer data dari buffer WaveRT ke perangkat keras audio). Struktur ini mencakup array 0 atau lebih struktur KSAUDIO_PACKETSIZE_PROCESSINGMODE_CONSTRAINT yang menjelaskan batasan khusus untuk mode pemrosesan sinyal apa pun. Driver mengatur properti ini sebelum memanggil PcRegisterSubdevice atau mengaktifkan antarmuka filter KS untuk pin streamingnya.

IMiniportWaveRTInputStream

Driver mengimplementasikan antarmuka ini untuk koordinasi aliran data audio yang lebih baik dari driver ke OS. Jika antarmuka ini tersedia pada aliran pengambilan, sistem operasi menggunakan metode pada antarmuka ini untuk mengakses data di dalam buffer WaveRT. Untuk informasi selengkapnya, lihat IMiniportWaveRTInputStream::GetReadPacket

IMiniportWaveRTOutputStream

Miniport WaveRT dapat secara opsional mengimplementasikan antarmuka ini untuk diberitahu tentang kemajuan penulisan dari OS dan untuk mengembalikan posisi aliran data yang tepat. Untuk informasi selengkapnya, lihat IMiniportWaveRTOutputStream::SetWritePacket, IMiniportWaveRTOutputStream::GetOutputStreamPresentationPosition dan IMiniportWaveRTOutputStream::GetPacketCount.

Tanda waktu penghitung kinerja

Beberapa rutinitas driver mengembalikan tanda waktu penghitung kinerja Windows yang mencerminkan waktu pengambilan sampel atau disajikan oleh perangkat.

Dalam perangkat yang memiliki alur DSP yang kompleks dan pemrosesan sinyal, menghitung tanda waktu yang akurat dapat menjadi tantangan dan harus dilakukan dengan bijaksana. Tanda waktu tidak boleh mencerminkan waktu di mana sampel ditransfer ke atau dari OS ke DSP.

  • Dalam DSP, lacak stempel waktu sampel menggunakan suatu jam dinding DSP internal.
  • Antara driver dan DSP, hitung korelasi antara penghitung kinerja Windows dan jam dinding DSP. Prosedur untuk ini dapat berkisar dari sederhana (tetapi kurang tepat) hingga cukup kompleks atau baru (tetapi lebih tepat).
  • Memperhitungkan penundaan tetap apa pun karena algoritma pemrosesan sinyal atau jalur pemrosesan atau perangkat keras, kecuali jika penundaan ini sudah diperhitungkan.

Operasi Baca Burst

Bagian ini menjelaskan interaksi OS dan driver untuk pembacaan burst. Burst read dapat terjadi di luar skenario aktivasi suara selama driver mendukung model WaveRT streaming berbasis paket, termasuk fungsi IMiniportWaveRTInputStream::GetReadPacket .

Dua contoh skenario baca burst dibahas. Dalam satu skenario, jika miniport mendukung pin yang memiliki kategori pin KSNODETYPE_AUDIO_KEYWORDDETECTOR maka driver mulai menangkap dan menyangga data secara internal saat kata kunci terdeteksi. Dalam skenario lain, driver dapat menyangga data secara internal di luar buffer WaveRT jika OS tidak membaca data dengan cukup cepat dengan memanggil IMiniportWaveRTInputStream::GetReadPacket.

Untuk meluaskan data yang telah diambil sebelum transisi ke KSSTATE_RUN, driver harus menyimpan informasi stempel waktu sampel yang akurat bersama dengan data pengambilan yang di-buffer. Tanda waktu mengidentifikasi instan pengambilan sampel sampel yang diambil.

  1. Setelah streaming beralih ke KSSTATE_RUN, driver segera mengatur peristiwa pemberitahuan buffer karena sudah memiliki data yang tersedia.

  2. Pada kejadian ini, OS memanggil GetReadPacket() untuk mendapatkan informasi tentang data yang tersedia.

    1. Driver mengembalikan nomor paket data yang diambil yang valid (0 untuk paket pertama setelah transisi dari KSSTATE_STOP ke KSSTATE_RUN), tempat OS dapat memperoleh posisi paket dalam buffer WaveRT dan posisi paket relatif terhadap awal aliran.

    2. Driver juga mengembalikan nilai penghitung kinerja yang sesuai dengan saat pengambilan sampel pertama dalam paket. Nilai penghitung kinerja ini mungkin relatif lama, tergantung pada berapa banyak data pengambilan yang telah di-buffer dalam perangkat keras atau driver (di luar buffer WaveRT).

    3. Jika ada lebih banyak data yang masih tersimpan di buffer belum dibaca, driver akan melakukan salah satu dari berikut ini:

      1. Segera mentransfer data tersebut ke ruang buffer WaveRT yang tersedia (yaitu, ruang yang tidak digunakan oleh paket yang dikembalikan dari GetReadPacket), mengembalikan nilai true untuk MoreData, dan mengatur peristiwa pemberitahuan buffer sebelum kembali dari proses ini. Atau,
      2. Program perangkat keras untuk meledakkan paket berikutnya ke ruang yang tersedia dari buffer WaveRT, mengembalikan false untuk MoreData, dan kemudian mengatur peristiwa buffer ketika transfer selesai.

  3. OS membaca data dari buffer WaveRT menggunakan informasi yang dikembalikan oleh GetReadPacket().

  4. OS menunggu peristiwa pemberitahuan buffer berikutnya. Penantian mungkin segera berakhir jika driver mengatur pemberitahuan buffer di langkah (2c).

  5. Jika driver tidak segera mengatur peristiwa di langkah (2c), driver mengatur peristiwa setelah mentransfer lebih banyak data yang diambil ke buffer WaveRT dan membuatnya tersedia bagi OS untuk dibaca

  6. Pergi ke (2). Untuk KSNODETYPE_AUDIO_KEYWORDDETECTOR pin detektor kata kunci, driver harus mengalokasikan buffering ledakan internal yang cukup untuk setidaknya 5000ms data audio. Jika sistem operasi gagal menghasilkan aliran pada pin sebelum buffer meluap, maka driver dapat mengakhiri aktivitas buffering internal dan membebaskan sumber daya terkait.

Bangun dengan Suara

Wake On Voice (WoV) memungkinkan pengguna mengaktifkan dan mengkueri mesin pengenal ucapan dari layar mati, status daya yang lebih rendah, ke layar aktif, status daya penuh dengan mengatakan kata kunci tertentu, seperti "Hey Cortana."

Fitur ini memungkinkan perangkat untuk selalu mendengarkan suara pengguna saat perangkat dalam keadaan daya rendah, termasuk ketika layar mati dan perangkat diam. Ini dilakukan dengan menggunakan mode mendengarkan, yang dayanya lebih rendah jika dibandingkan dengan penggunaan daya yang lebih tinggi yang terlihat selama perekaman mikrofon normal. Pengenalan suara berdaya rendah memungkinkan pengguna untuk mengatakan kata kunci yang telah ditentukan sebelumnya seperti "Hey Cortana," diikuti dengan perintah suara berantai seperti "kapan janji saya berikutnya" untuk mengaktifkan pengenalan suara dengan cara bebas tangan. Ini berfungsi terlepas dari apakah perangkat sedang digunakan atau diam dengan layar mati.

Rangkaian audio bertanggung jawab untuk mengomunikasikan data bangun (ID pembicara, pemicu kata kunci, tingkat keyakinan) dan memberitahu klien yang tertarik bahwa kata kunci telah terdeteksi.

Validasi pada Sistem Siaga Modern

WoV dari status diam sistem dapat divalidasi pada sistem Siaga Modern menggunakan Modern Standby Wake on Voice Basic Test pada AC-power Source dan Modern Standby Wake on Voice Basic Test pada DC-power Source di HLK. Pengujian ini memeriksa bahwa sistem memiliki pengenal kata kunci perangkat keras (HW-KWS), dapat memasuki Status Platform Idle Runtime Terdalam (DRIPS) dan dapat bangun dari Mode Siaga Modern dengan perintah suara dengan latensi resume sistem dalam waktu kurang dari atau sama dengan satu detik.

  • Last updated on