Pemicu Suara

Fitur Pemicu Suara memberi aplikasi kemampuan untuk memproses peristiwa akustik tertentu, seperti kata kunci 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 menerapkan antarmuka Sound Trigger HAL (STHAL).

  Catatan: Sebaiknya gunakan penerapan langsung antarmuka STHAL, bukan sebagai adaptor untuk 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 (dalam warna 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 buram terhadap framework di subsistem Pemicu Suara, aplikasi dan implementasi HAL diharapkan mempertahankan “kontrak tersembunyi”, yaitu, konten, format, dan semantik sebenarnya dari jenis data tersebut telah 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 Pemicu Suara, dan menangani pengenalan hardware terhadap frasa pengaktif dan suara lainnya. STHAL menyediakan satu atau beberapa mesin dengan masing-masing mesin menjalankan algoritma yang 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:

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 yang 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 nanti, dan proses ini dapat diulangi sebanyak yang diperlukan.

3. Terakhir, model tidak aktif yang tidak lagi diperlukan 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. Sebaliknya, status model tetap berjalan bahkan setelah peristiwa dikirim.

Menangani error HAL

Untuk memastikan perilaku yang andal dan konsisten antar-implementasi driver, di Android 11, setiap kode error yang tidak berhasil dan ditampilkan dari HAL diperlakukan sebagai error pemrograman, yang pemulihannya memerlukan awal 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 terkait kapan dan dalam status apa kode error ini ditampilkan dan 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.