Pemicu Suara

Fitur Pemicu Suara memberi aplikasi kemampuan untuk memproses peristiwa akustik tertentu, seperti kata panas, dengan cara yang hemat daya dan sensitif terhadap privasi. Contoh kasus penggunaan Pemicu Suara adalah Asisten dan Sedang Diputar.

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

Stack Pemicu Suara

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

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).

  Catatan: Implementasi langsung antarmuka STHAL direkomendasikan, bukan sebagai adaptor di sekitar implementasi HAL lama.

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

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

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

Fungsi stack Pemicu Suara adalah untuk mengirimkan peristiwa terpisah yang mewakili peristiwa pemicu akustik. Pada umumnya, stack Pemicu Suara tidak menangani audio. Setelah menerima peristiwa pemicu, aplikasi mendapatkan akses ke streaming audio yang sebenarnya, yang mengelilingi waktu peristiwa, dengan membuka objek AudioRecord melalui framework Audio. Sound Trigger HAL API 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.

Catatan: Karena model dan jenis data tidak transparan untuk framework dalam subsistem Pemicu Bunyi, aplikasi dan implementasi HAL diharapkan mempertahankan "kontrak tersembunyi", yaitu konten, format, dan semantik sebenarnya dari jenis data tersebut disepakati. Oleh karena itu, aplikasi yang menggunakan Pemicu Suara dimaksudkan untuk disediakan oleh vendor, bukan oleh developer independen.

Antarmuka HAL Pemicu Suara

Antarmuka Sound Trigger HAL (STHAL) adalah bagian khusus vendor dari stack Sound Trigger dan menangani pengenalan hardware kata kunci panas dan suara lainnya. STHAL menyediakan satu atau beberapa mesin dengan masing-masing mesin menjalankan algoritma yang berbeda yang dirancang untuk mendeteksi class 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 dalam Gambar 2:

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 disediakan menunjukkan algoritma deteksi (mesin) khusus penerapan mana 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 terus berjalan di latar belakang hingga salah satu peristiwa berikut terjadi:

   1. stopRecognition() telah dipanggil pada model ini.
   2. Deteksi telah terjadi.
   3. Deteksi dibatalkan karena keterbatasan 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 dimuat. 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 diulang sebanyak yang diperlukan.

3. Terakhir, model tidak aktif yang tidak lagi diperlukan akan di-unload oleh klien HAL melalui unloadModel().

Catatan: Saat model dimulai, klien HAL dapat memanggil forceRecognitionEvent() untuk menghasilkan peristiwa pengenalan paksa. Peristiwa yang ditampilkan mirip dengan peristiwa pengenalan normal, tetapi kolom statusnya ditetapkan ke FORCED. Peristiwa pengenalan tersebut tidak otomatis menghentikan pengenalan. Sebagai gantinya, status model tetap berjalan bahkan setelah peristiwa dikirim.

Menangani error HAL

Untuk memastikan perilaku yang andal dan konsisten di antara implementasi driver, di Android 11, kode error non-sukses yang ditampilkan dari HAL akan diperlakukan sebagai error pemrograman, yang pemulihannya memerlukan memulai ulang proses HAL. Ini adalah strategi pemulihan upaya terakhir dan harapannya adalah kasus tersebut tidak akan terjadi dalam sistem yang berfungsi dengan baik.

Catatan: Meskipun error ini disebut valid dalam dokumentasi HAL API, ada ambiguitas tentang kapan dan dalam status apa kode error ini ditampilkan dan apa prosedur pemulihan error yang diharapkan. Oleh karena itu, Android 11 mewajibkan kepatuhan yang lebih ketat terhadap implementasi HAL Pemicu Suara saat runtime daripada Android versi yang lebih rendah.