Điều kiện kích hoạt âm thanh

Tính năng Kích hoạt bằng âm thanh giúp các ứng dụng có khả năng theo dõi một số sự kiện âm thanh nhất định (chẳng hạn như từ khoá kích hoạt) theo cách tiêu thụ ít năng lượng và đảm bảo quyền riêng tư. Các trường hợp sử dụng minh hoạ của tính năng Kích hoạt bằng âm thanh là Trợ lý và tính năng Đang phát.

Trang này cung cấp thông tin tổng quan về cấu trúc Sound Trigger và giao diện HAL (Lớp trừu tượng phần cứng) của cấu trúc này.

Ngăn xếp Sound Trigger

Hệ thống con Sound Trigger được tạo thành từ nhiều lớp như trong Hình 1:

Hình 1: Ngăn xếp Sound Trigger

Danh sách sau đây mô tả chi tiết hơn về từng lớp xuất hiện trong Hình 1:

• Lớp HAL (màu xanh lục) chứa mã dành riêng cho nhà cung cấp để triển khai giao diện Sound Trigger HAL (STHAL).

  Lưu ý: Bạn nên triển khai trực tiếp giao diện STHAL thay vì dùng làm bộ chuyển đổi cho một phương thức triển khai HAL cũ.

• SoundTriggerMiddleware (màu vàng) nằm phía trên giao diện HAL. Nó giao tiếp với HAL và chịu trách nhiệm về các chức năng như chia sẻ HAL giữa các ứng dụng, ghi nhật ký, thực thi quyền và xử lý khả năng tương thích với các phiên bản HAL cũ.

• Hệ thống SoundTriggerService (màu xanh dương) nằm phía trên phần mềm trung gian. Nó hỗ trợ việc tích hợp với các tính năng khác của hệ thống, chẳng hạn như các sự kiện về pin và điện thoại. Hệ thống này cũng duy trì một cơ sở dữ liệu gồm các mẫu âm thanh, được lập chỉ mục theo mã nhận dạng duy nhất.

• Phía trên lớp SoundTriggerService, ngăn xếp (màu nâu) xử lý riêng các tính năng dành riêng cho Trợ lý và các ứng dụng chung.

Chức năng của ngăn xếp Sound Trigger là truyền tải các sự kiện rời rạc đại diện cho các sự kiện kích hoạt âm thanh. Trong hầu hết các trường hợp, ngăn xếp Sound Trigger không xử lý âm thanh. Khi nhận được các sự kiện kích hoạt, ứng dụng sẽ có quyền truy cập vào luồng âm thanh thực tế, bao quanh thời gian của các sự kiện, bằng cách mở một đối tượng AudioRecord thông qua Khung âm thanh. Các API HAL của Trình kích hoạt âm thanh cung cấp một thao tác với sự kiện được kích hoạt dùng với Khung âm thanh. Do đó, vì Sound Trigger HAL và Audio HAL được kết nối ngầm, nên chúng thường dùng chung một quy trình.

Lưu ý: Vì các mô hình và kiểu dữ liệu không rõ ràng đối với khung trong hệ thống con Sound Trigger, nên các ứng dụng và việc triển khai HAL dự kiến sẽ duy trì "hợp đồng ẩn", tức là nội dung, định dạng và ngữ nghĩa thực tế của những kiểu dữ liệu đó được thoả thuận. Do đó, các ứng dụng sử dụng Sound Trigger là do nhà cung cấp cung cấp chứ không phải do các nhà phát triển độc lập.

Giao diện HAL của Trình kích hoạt âm thanh

Giao diện HAL của Trình kích hoạt âm thanh (STHAL) là phần dành riêng cho nhà cung cấp của ngăn xếp Trình kích hoạt âm thanh và giao diện này xử lý hoạt động nhận dạng phần cứng của từ khoá kích hoạt và các âm thanh khác. STHAL cung cấp một hoặc nhiều công cụ, mỗi công cụ chạy một thuật toán khác nhau được thiết kế để phát hiện một lớp âm thanh cụ thể. Khi phát hiện thấy một điều kiện kích hoạt, STHAL sẽ gửi một sự kiện đến khung rồi dừng phát hiện.

Giao diện STHAL được chỉ định trong /hardware/interfaces/soundtrigger/.

Giao diện ISoundTriggerHw hỗ trợ khả năng chạy một hoặc nhiều phiên phát hiện tại một thời điểm nhất định và theo dõi các sự kiện âm thanh. Lệnh gọi đến ISoundTriggerHw.getProperties() sẽ trả về một cấu trúc Properties chứa nội dung mô tả và các chức năng triển khai.

Quy trình cơ bản để thiết lập một phiên được giải thích như sau trong Hình 2:

Hình 2: Sơ đồ trạng thái STHAL

Các bước sau đây mô tả chi tiết hơn về từng trạng thái:

1. Ứng dụng HAL tải một mô hình bằng cách sử dụng loadSoundModel() hoặc loadPhraseSoundModel(). Đối tượng mô hình được cung cấp cho biết nên sử dụng thuật toán (công cụ) phát hiện cụ thể theo từng cách triển khai nào, cũng như các tham số áp dụng cho thuật toán này. Khi thành công, các phương thức này sẽ trả về một giá trị nhận dạng dùng để tham chiếu mô hình này trong các lệnh gọi tiếp theo.

2. Sau khi mô hình được tải thành công, ứng dụng HAL sẽ gọi startRecognition() để bắt đầu phát hiện. Hoạt động nhận dạng sẽ tiếp tục chạy ở chế độ nền cho đến khi một trong các sự kiện sau đây xảy ra:

   1. Một stopRecognition() đã được gọi trên mô hình này.
   2. Đã xảy ra một sự kiện phát hiện.
   3. Quá trình phát hiện bị huỷ do hạn chế về tài nguyên, ví dụ: khi một trường hợp sử dụng có mức độ ưu tiên cao hơn đã được bắt đầu.

   Trong 2 trường hợp sau, một sự kiện nhận dạng sẽ được gửi thông qua giao diện gọi lại mà ứng dụng HAL đăng ký khi tải. Trong mọi trường hợp, sau khi bất kỳ sự kiện nào trong số này xảy ra, quá trình phát hiện sẽ không hoạt động và không được phép có thêm lệnh gọi lại nhận dạng.

   Bạn có thể khởi động lại cùng một mô hình vào lúc khác và lặp lại quy trình này bao nhiêu lần tuỳ ý.

3. Cuối cùng, một mô hình không hoạt động và không còn cần thiết sẽ được HAL client huỷ tải thông qua unloadModel().

Lưu ý: Khi một mô hình được khởi động, ứng dụng HAL có thể gọi forceRecognitionEvent() để tạo một sự kiện nhận dạng bắt buộc. Sự kiện được trả về tương tự như một sự kiện nhận dạng thông thường, nhưng trường trạng thái của sự kiện đó được đặt thành FORCED. Những sự kiện nhận dạng như vậy không tự động dừng quá trình nhận dạng. Thay vào đó, trạng thái mô hình vẫn chạy ngay cả sau khi sự kiện được phân phối.

Xử lý lỗi HAL

Để đảm bảo hành vi nhất quán và đáng tin cậy giữa các cách triển khai trình điều khiển, trong Android 11, mọi mã lỗi không thành công được trả về từ HAL đều được coi là lỗi lập trình. Để khắc phục, bạn cần khởi động lại quy trình HAL. Đây là chiến lược khôi phục cuối cùng và chúng tôi hy vọng rằng những trường hợp như vậy sẽ không xảy ra trong một hệ thống hoạt động đúng cách.

Lưu ý: Mặc dù những lỗi này được gọi là hợp lệ trong tài liệu HAL API, nhưng vẫn có sự mơ hồ về thời điểm và trạng thái mà các mã lỗi này được trả về, cũng như quy trình khôi phục lỗi dự kiến. Do đó, Android 11 yêu cầu việc triển khai HAL Kích hoạt âm thanh phải tuân thủ nghiêm ngặt hơn trong thời gian chạy so với các phiên bản Android thấp hơn.