Monophone Background Model for Wakeword Detection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Speech recognition systems face challenges in efficiently detecting wake words due to limited computational capacity in devices, leading to excessive resource consumption and errors in trigger detection, such as missed triggers and false alarms.
Innovation Solution
A spoken language processing system that employs a monophone background model using a Hidden Markov Model (HMM) with a trigger detector, which processes audio data locally to reduce unnecessary data transmission and improve detection accuracy by using a feature extractor and analyzer to generate feature vectors and observation vectors, and a trigger detector to identify wake words with low error rates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If speech recognition is performed to determine speaker intent, then accurate word recognition is achieved, but computational cost becomes excessive for devices with limited capacity
Solution Approach 1:
The speech recognition system is segmented into two parts: a lightweight wakeword detection module that runs locally on the device with limited computational resources, and a full speech recognition module that runs on the server with abundant computational resources. This segmentation allows the device to perform only essential local processing while offloading complex recognition tasks.
Solution Approach 2:
The system performs preliminary wakeword detection locally before initiating full speech recognition on the server. By detecting the wakeword in advance using a simplified model, the system prepares the conditions for subsequent full recognition, avoiding unnecessary server communication when no wake command is present.
2Measurement precision
If devices send audio data continuously to the server, then accurate interpretation is achieved, but communication resources are excessively consumed
Solution Approach 1:
Instead of continuous audio transmission, the system uses periodic communication triggered by local wakeword detection. The device monitors audio continuously for the wakeword pattern and only establishes server communication when the trigger is detected, transforming continuous resource consumption into event-driven periodic action.
Solution Approach 2:
The wakeword detection system acts as an intermediary between the microphone and the server communication channel. It filters incoming audio streams and only permits transmission to the server when the wakeword condition is met, thereby mediating resource consumption between continuous monitoring and selective communication.
3Productivity
If a lightweight detection model is used on the device, then computational capacity is preserved, but trigger detection errors increase
Solution Approach 1:
The system replaces the mechanical approach of running a single complex recognition model on the device with a substituted architecture using acoustic feature extraction and simplified pattern matching for wakeword detection. This substitution enables lightweight local processing while maintaining acceptable detection accuracy through optimized feature representation.
Data Source
AI summary
An approach to wakeword detection uses an explicit representation of non-wakeword speech in the form of subword (e.g., phonetic monophone) units that do not necessarily occur in the wakeword and that broadly represent general speech. These subword units are arranged in a “background” model, which at runtime essentially competes with the wakeword model such that a wakeword is less likely to be declare as occurring when the input matches that background model well. An HMM may be used with the model to locate possible occurrences of the wakeword. Features are determined from portions of the input corresponding to subword units of the wakeword detected using the HMM. A secondary classifier is then used to process the features to yield a decision of whether the wakeword occurred.