Pemicu Suara

Fitur Pemicu Suara memberi aplikasi kemampuan untuk mendengarkan peristiwa akustik tertentu, seperti kata cepat, dengan daya yang rendah dan cara yang sensitif terhadap privasi. Contoh kasus penggunaan Sound Trigger adalah Assistant dan Now Playing.

Halaman ini memberikan gambaran umum tentang arsitektur Sound Trigger dan antarmuka HAL (Hardware Abstraction Layer).

Tumpukan Pemicu Suara

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

sound_trigger_stack

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

  • SoundTriggerMiddleware (berwarna kuning) berada di atas antarmuka HAL. Ini berkomunikasi dengan HAL dan bertanggung jawab untuk 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. Itu juga memelihara database model suara, diindeks oleh ID unik.

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

Fungsi tumpukan Pemicu Suara adalah untuk menghadirkan peristiwa terpisah yang mewakili akustik, peristiwa pemicu. Dalam kebanyakan kasus, tumpukan Pemicu Suara tidak menangani audio. Setelah menerima peristiwa pemicu, aplikasi mendapatkan akses ke aliran audio aktual, di sekitar waktu peristiwa, dengan membuka objek AudioRecord melalui kerangka kerja Audio. API HAL Pemicu Suara menyediakan pegangan dengan peristiwa yang dipicu yang digunakan dengan Kerangka Kerja Audio. Oleh karena itu, karena Sound Trigger HAL dan Audio HAL terhubung di bawah kap, mereka biasanya berbagi proses.

Antarmuka HAL Pemicu Suara

Antarmuka Sound Trigger HAL (STHAL) adalah bagian khusus vendor dari tumpukan Sound Trigger dan menangani pengenalan perangkat keras dari kata cepat dan suara lainnya. STHAL menyediakan satu atau lebih mesin dengan masing-masing menjalankan algoritme berbeda yang dirancang untuk mendeteksi kelas suara tertentu. Saat 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 untuk 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:

sthal_state

Gambar 2: Diagram status 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 algoritme deteksi spesifik implementasi (mesin) mana yang akan digunakan, serta parameter yang berlaku untuk algoritme ini. Setelah berhasil, metode ini mengembalikan pegangan yang digunakan untuk mereferensikan model ini dalam 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. Sebuah stopRecognition() telah dipanggil pada model ini.
    2. Deteksi telah terjadi.
    3. Deteksi dibatalkan karena kendala 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 salah satu peristiwa ini terjadi, deteksi menjadi tidak aktif dan tidak ada lagi panggilan balik 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 diturunkan oleh klien HAL melalui unloadModel() .

Penanganan 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, pemulihan yang memerlukan proses ulang HAL. Ini adalah strategi pemulihan pilihan terakhir dan harapannya adalah kasus seperti itu tidak akan terjadi dalam sistem yang berfungsi dengan baik.