Pemicu Suara

Fitur Pemicu Suara memberi aplikasi kemampuan untuk memproses peristiwa akustik tertentu, seperti kata kunci, dengan cara yang hemat daya dan memperhatikan privasi. Contoh kasus penggunaan Pemicu Suara adalah Asisten dan Now Playing.

Halaman ini memberikan ringkasan arsitektur Pemicu Suara dan antarmuka HAL (Hardware Abstraction Layer).

Stack Pemicu Suara

Subsistem Pemicu Suara dibangun dalam lapisan seperti yang ditunjukkan pada Gambar 1:

sound_trigger_stack

Gambar 1: Stack Pemicu Suara

Daftar berikut menjelaskan setiap lapisan yang ditampilkan dalam Gambar 1 secara lebih mendetail:

  • Lapisan HAL (berwarna hijau) berisi kode khusus vendor yang mengimplementasikan antarmuka Sound Trigger HAL (STHAL).

  • SoundTriggerMiddleware (berwarna kuning) berada di atas antarmuka HAL. Layanan ini berkomunikasi dengan HAL dan bertanggung jawab atas fungsi seperti berbagi HAL antara klien yang berbeda, logging, menerapkan izin, dan menangani kompatibilitas dengan versi HAL yang lebih lama.

  • Sistem SoundTriggerService (berwarna biru) berada di atas middleware. Layanan ini memfasilitasi integrasi dengan fitur sistem lainnya, seperti peristiwa telepon dan baterai. Fitur ini juga mengelola database model suara, yang diindeks berdasarkan ID unik.

  • Di atas lapisan SoundTriggerService, stack (berwarna cokelat) menangani fitur khusus Asisten dan aplikasi generik secara terpisah.

Fungsi stack Pemicu Suara adalah untuk mengirimkan peristiwa diskrit yang mewakili peristiwa pemicu akustik. Dalam sebagian besar kasus, stack Pemicu Suara tidak menangani audio. Setelah menerima peristiwa pemicu, aplikasi akan mendapatkan akses ke streaming audio sebenarnya, di sekitar waktu terjadinya peristiwa, dengan membuka objek AudioRecord melalui framework Audio. API HAL Pemicu Suara menyediakan handle dengan peristiwa yang dipicu yang digunakan dengan Audio Framework. Oleh karena itu, karena Sound Trigger HAL dan Audio HAL terhubung di balik layar, keduanya biasanya berbagi proses.

Antarmuka HAL Pemicu Suara

Antarmuka Sound Trigger HAL (STHAL) adalah bagian khusus vendor dari stack Sound Trigger dan menangani pengenalan hardware untuk frasa pengaktif dan suara lainnya. STHAL menyediakan satu atau beberapa mesin yang masing-masing menjalankan algoritma berbeda yang dirancang untuk mendeteksi kelas suara tertentu. Saat mendeteksi pemicu, STHAL akan mengirim peristiwa ke framework, lalu menghentikan deteksi.

Antarmuka STHAL ditentukan di bagian /hardware/interfaces/soundtrigger/.

Antarmuka ISoundTriggerHw mendukung kemampuan untuk menjalankan satu atau beberapa sesi deteksi pada waktu tertentu dan memproses peristiwa akustik. Panggilan ke ISoundTriggerHw.getProperties() menampilkan struktur Properties yang berisi deskripsi dan kemampuan implementasi.

Alur dasar penyiapan sesi dijelaskan sebagai berikut pada Gambar 2:

sthal_state

Gambar 2: Diagram status STHAL

Langkah-langkah berikut menjelaskan setiap status secara lebih mendetail:

  1. Klien HAL memuat model menggunakan loadSoundModel() atau loadPhraseSoundModel(). Objek model yang diberikan menunjukkan algoritma (mesin) deteksi khusus penerapan yang akan digunakan, serta parameter yang berlaku untuk algoritma ini. Setelah berhasil, metode ini akan menampilkan handle yang digunakan untuk mereferensikan model ini dalam panggilan berikutnya.

  2. Setelah model berhasil dimuat, klien HAL akan memanggil startRecognition() untuk memulai deteksi. Pengenalan akan terus berjalan di latar belakang hingga salah satu peristiwa berikut terjadi:

    1. stopRecognition() telah dipanggil pada model ini.
    2. Terjadi deteksi.
    3. Deteksi dibatalkan karena batasan resource, misalnya, saat kasus penggunaan dengan prioritas lebih tinggi telah dimulai.

    Dalam dua kasus terakhir, peristiwa pengenalan dikirim melalui antarmuka callback yang didaftarkan oleh klien HAL saat memuat. Dalam semua kasus, setelah salah satu peristiwa ini terjadi, deteksi menjadi tidak aktif dan tidak ada lagi callback pengenalan yang diizinkan.

    Model yang sama dapat dimulai lagi di lain waktu, dan proses ini dapat diulangi sebanyak yang diperlukan.

  3. Terakhir, model tidak aktif yang tidak lagi diperlukan dibongkar oleh klien HAL melalui unloadModel().

Menangani error HAL

Untuk memastikan perilaku yang andal dan konsisten di antara implementasi driver, di Android 11, kode error non-berhasil apa pun yang ditampilkan dari HAL dianggap sebagai error pemrograman, yang pemulihannya memerlukan memulai ulang proses HAL. Ini adalah strategi pemulihan upaya terakhir dan diharapkan kasus seperti ini tidak akan terjadi pada sistem yang berfungsi dengan baik.