Sound Trigger in Android

If you are working with apps that require you to cater to sounds that are in the user’s surroundings then you no longer need to work with other third-party APIs because Google just announced improvements to their previously acclaimed Sound Trigger functionality.

What is Sound Trigger

With the help of the Sound Trigger function, apps can listen for certain acoustic events, such as hot words, in a low-power and privacy-conscious manner. Examples of Sound Trigger applications include Assistant and Now Playing. In this article, we will understand what the Sound Trigger feature is, and try to dive deeper into the topic. The HAL (Hardware Abstraction Layer) interface of the Sound Trigger architecture will also be elaborated on in this article, so keep reading.

Understanding the Architecture of the HAL Core Layer

The Image below tells us about the various components which are present in the HAL Core layer, we will be discussing each stage in detail after discussing the diagram.

Image #1: Understanding the HAL Architecture

The layers involved are:

1. The vendor-specific code that implements the Sound Trigger HAL (STHAL) interface is found in the HAL layer (in green).
2. Over the HAL interface is where the SoundTriggerMiddleware (in yellow) is located. It interacts with the HAL and is in charge of functions including logging, enforcing permissions, sharing the HAL among many clients, and managing compatibility with earlier HAL versions.
3. The SoundTriggerService system is located above the middleware (in blue). It makes it easier to integrate additional system components like telephone and battery events. It also keeps a database of sound models that is organized by distinctive IDs.
4. The stack (shown in brown) above the SoundTriggerService layer manages capabilities unique to Assistant and universal apps independently.

GeekTip #1: For better performance you should use the HAL service directly, rather than using some other adapter service for doing the work, as it will introduce some latency in the middle otherwise.

Using the Sound Core with Audio Manager

Delivering discrete events that reflect acoustic trigger events is the job of the Sound Trigger stack. The Sound Trigger stack often doesn’t deal with audio. When trigger events are received, apps open an AudioRecord object using the Audio framework to access the actual audio stream that was playing at the time the events were occurring. The handle with the triggered event is provided by the Sound Trigger HAL APIs for usage with the Audio Framework. As a result, because the Sound Trigger HAL and Audio HAL are linked internally, they frequently share a process.

How Sound Trigger works with HAL

The vendor-specific component of the Sound Trigger stack, the Sound Trigger HAL (STHAL) interface, handles the hardware recognition of hot words and other sounds. STHAL offers one or more engines, each of which is running a unique algorithm made to identify a certain class of sounds. After sending an event to the framework and ceasing further detection after detecting a trigger, STHAL. Under /hardware/interfaces/soundtrigger/, the STHAL interface is described.

The ISoundTriggerHw interface enables the ability to listen to acoustic events and execute one or more detection sessions concurrently. SoundTriggerHw.getProperties() produces a Properties structure with information about the implementation’s capabilities.

Understanding the Sound Core Layers

We will now look at how the Sound Core Trigger works with the preset of HAL, and then move forward with its implementation, so far we have only seen how HAL works separately. The following stages happen in the backend, whenever the Sound Trigger is paired:

1. Using loadSoundModel() or loadPhraseSoundModel, the HAL client loads a model(). The given model object specifies the detection algorithm (engine) to use, along with the parameters that apply to this algorithm. Upon successful completion, these methods return a handle that can be used in later calls to refer to this model.
2. The HAL client calls startRecognition() to start the detection process when the model has been loaded successfully. Up to one of the following occasions, recognition runs in the background:
3. On this model, a stopRecognition() call has been made.
4. A finding has been made.

GeekTip #2: Due to resource limitations, detection may be stopped, as when a use case with a greater priority has been started.

Encountering the errors that occur using HAL

In Android 11, all non-success error codes issued by the HAL are handled as programming errors, and recovering from them necessitates restarting the HAL process in order to maintain dependable and consistent behavior between driver implementations. Since such circumstances are unlikely to arise in a system that is functioning properly, this recovery approach should only be used as a last resort.

Conclusion

Although these failures are acknowledged as legitimate in the HAL API specification, it is unclear when and under what conditions they are returned, as well as what the anticipated error recovery process is. Hope you have learned something new in this Geeks for Geeks article, and will implement the Sound Trigger functionality app to get rid of the other third-party implementation also as a result, compared to earlier versions of Android, Android 11 requires stronger conformity of Sound Trigger HAL implementations during runtime.