Pemicu Suara

Fitur Pemicu Suara memberi aplikasi kemampuan untuk mendengarkan peristiwa akustik tertentu, seperti kata cepat, dengan daya rendah dan peka terhadap privasi. Contoh kasus penggunaan Pemicu Suara adalah Asisten dan Sedang Diputar.

Halaman ini memberikan ikhtisar arsitektur Sound Trigger dan antarmuka HAL (Hardware abstraction layer).

Tumpukan Pemicu Suara

Subsistem Sound Trigger dibangun berlapis-lapis seperti yang ditunjukkan pada Gambar 1:

Gambar 1: Tumpukan Pemicu Suara

Daftar berikut menjelaskan setiap lapisan yang ditunjukkan pada Gambar 1 secara lebih rinci:

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

  Catatan: Implementasi langsung dari antarmuka STHAL direkomendasikan daripada sebagai adaptor di sekitar implementasi HAL lama.

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

• Sistem SoundTriggerService (berwarna biru) berada di atas middleware. Ini memfasilitasi integrasi dengan fitur sistem lainnya, seperti acara telepon dan baterai. Ia juga memelihara database model suara, yang diindeks berdasarkan ID unik.

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

Fungsi tumpukan Sound Trigger adalah untuk menghadirkan peristiwa diskrit yang mewakili peristiwa pemicu akustik. Dalam kebanyakan kasus, tumpukan Sound Trigger tidak menangani audio. Setelah menerima peristiwa pemicu, aplikasi mendapatkan akses ke aliran audio aktual, sekitar waktu peristiwa, dengan membuka objek AudioRecord melalui kerangka Audio. Sound Trigger HAL API menyediakan penanganan peristiwa yang dipicu yang digunakan dengan Audio Framework. Oleh karena itu, karena Sound Trigger HAL dan Audio HAL dihubungkan di bawah kap, keduanya biasanya berbagi proses.

Catatan: Karena model dan tipe data tidak tembus pandang terhadap kerangka kerja di subsistem Pemicu Suara, diharapkan aplikasi dan implementasi HAL mempertahankan “kontrak tersembunyi”, yaitu konten, format, dan semantik sebenarnya dari tipe data tersebut disepakati pada. Oleh karena itu, aplikasi yang menggunakan Sound Trigger dimaksudkan untuk disediakan oleh vendor, bukan oleh pengembang independen.

Antarmuka HAL Pemicu Suara

Antarmuka Sound Trigger HAL (STHAL) adalah bagian khusus vendor dari tumpukan Sound Trigger dan menangani pengenalan perangkat keras terhadap kata cepat dan suara lainnya. STHAL menyediakan satu atau lebih mesin yang masing-masing menjalankan algoritma berbeda yang dirancang untuk mendeteksi kelas suara tertentu. Ketika STHAL mendeteksi pemicu, ia mengirimkan peristiwa ke kerangka kerja dan kemudian menghentikan deteksi.

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

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

Alur dasar pengaturan sesi dijelaskan sebagai berikut pada Gambar 2:

Gambar 2: Diagram keadaan STHAL

Langkah-langkah berikut menjelaskan setiap negara bagian secara lebih rinci:

1. Klien HAL memuat model menggunakan loadSoundModel() atau loadPhraseSoundModel() . Objek model yang disediakan menunjukkan algoritma deteksi spesifik implementasi (mesin) mana yang akan digunakan, serta parameter yang berlaku untuk algoritma ini. Setelah berhasil, metode ini mengembalikan pegangan yang digunakan untuk mereferensikan model ini pada panggilan berikutnya.

2. Setelah model berhasil dimuat, klien HAL 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 sumber daya, misalnya, ketika kasus penggunaan dengan prioritas lebih tinggi telah dimulai.

   Dalam dua kasus terakhir, peristiwa pengenalan dikirim melalui antarmuka panggilan balik yang didaftarkan oleh klien HAL saat memuat. Dalam semua kasus, setelah kejadian ini terjadi, deteksi menjadi tidak aktif dan callback pengenalan tidak diperbolehkan lagi.

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

Catatan: Saat model dimulai, klien HAL dapat memanggil forceRecognitionEvent() untuk menghasilkan peristiwa pengenalan paksa. Peristiwa yang dikembalikan mirip dengan peristiwa pengenalan normal, tetapi bidang statusnya disetel ke FORCED . Peristiwa pengakuan tersebut tidak serta merta menghentikan pengakuan tersebut. Sebaliknya, status model tetap berjalan bahkan setelah peristiwa dikirimkan.

Menangani kesalahan HAL

Untuk memastikan perilaku yang andal dan konsisten di antara implementasi driver, di Android 11, setiap kode kesalahan yang tidak berhasil yang dikembalikan dari HAL diperlakukan sebagai kesalahan pemrograman, dan pemulihannya memerlukan memulai ulang proses HAL. Ini adalah strategi pemulihan pilihan terakhir dan diharapkan kasus seperti ini tidak akan terjadi jika sistem berjalan dengan baik.

Catatan: Meskipun kesalahan ini dianggap valid dalam dokumentasi HAL API, terdapat ketidakpastian mengenai kapan dan dalam keadaan apa kode kesalahan ini dikembalikan dan apa prosedur pemulihan kesalahan yang diharapkan. Oleh karena itu, Android 11 mewajibkan kepatuhan yang lebih ketat terhadap penerapan Sound Trigger HAL saat runtime dibandingkan versi Android yang lebih rendah.