Sonus: an always-listening hotword layer for Node

The offline trigger, then the cloud

Sonus is described as a dead simple STT library in Node, and the mechanism is the interesting part. The library is always listening offline for a customizable hotword, in the same way that Alexa, Google Assistant and Siri are. Once the hotword is detected, your speech is streamed to the cloud recognition service of your choice and the results come back in realtime. That split is the whole design. The trigger does not need a network connection and does not need to be accurate about what you said, it only needs to know that you started talking, which is a much easier problem than transcription, and it is the reason the library can feel instant while the recognition is not. The package description puts it more grandly as an open source cross platform decentralized always-on speech recognition framework, and the topics list adds keyword spotting and voice control to the usual speech to text vocabulary.

The platform and service matrix is short and honest

The README keeps a checklist of what works, and it is worth reading because several boxes are empty. Platform support is checked for Linux on most major distributions including Raspbian, and checked for macOS, while Windows is listed and unchecked. Streaming recognition services has Google Cloud Speech checked, while Alexa Voice Services, Wit.ai, Microsoft Cognitive Services and Houndify are all listed and unchecked. So the supported path is one recogniser and two operating systems, which is honest but narrower than the feature list implies. The library itself is agnostic, since the recogniser is passed in as a client, so the unchecked boxes are the state of the provided integrations rather than a hard architectural limit. The consequence for a user is that Google Cloud Speech is the path with a documented example, and everything else is on you to wire up, and the Windows gap is the one that will stop a project outright.

Installing it and the SoX dependency

The package itself installs from npm:

npm install --save sonus

Running npm install is generally sufficient, but the README notes that the module also requires you to install SoX, which is the audio toolkit that does the recording. On most Linux distributions the recommended route is arecord, which comes with most Linux distros, and the alternative is installing the package:

sudo apt-get install sox libsox-fmt-all

On macOS it is a Homebrew install:

brew install sox

The `libsox-fmt-all` part is not decoration. SoX is used through the `node-record-lpcm16` dependency, which is in the package dependencies at version 0.3.1, and that is a 16 bit PCM recorder, so the format support packages are what make the recording actually work rather than fail at startup. A Raspberry Pi is the obvious target device here, and the fact that the Linux package list is the first one in the README is a hint about who this is for.

Wiring it to Google Cloud Speech

The usage path starts by configuring the cloud recognition system of your choice, with the Google Cloud Speech API given as the example, and by creating the client that Sonus will stream to:

const Sonus = require('sonus')
const speech = require('@google-cloud/speech')
const client = new speech.SpeechClient()

There is one credential detail that is easy to miss. The README notes that you need to use the `GOOGLE_APPLICATION_CREDENTIALS` environment variable for your JSON keyfile, or check the examples to see how the keyfile path can be passed in. So the authentication is the standard Google Cloud mechanism rather than something Sonus reimplements, and the examples directory in the repository holds a working variant for each approach. The dependency list confirms the shape, with `@google-cloud/speech` at version 2.1.2 or newer, `node-record-lpcm16` for the microphone, and `snowboy` pinned at `1.3.1-alpha.1` for the hotword detection.

The hotword model and the three lines of setup

The rest of the integration is small enough to read in one breath. You declare the hotwords with the file of a trained model and the word itself, and initialise Sonus with those hotwords and the client:

const hotwords = [{ file: 'resources/snowboy.umdl', hotword: 'snowboy' }]
const sonus = Sonus.init({ hotwords }, client)

Then you start it and subscribe to the events, with the hotword event giving you the index and the keyword, and the final-result event carrying the recognised text:

Sonus.start(sonus)
sonus.on('hotword', (index, keyword) => console.log("!"))
sonus.on('final-result', console.log)

The hotword detection is Snowboy, which is a separate project from Sonus. You train a model for a new hotword through the Snowboy website or its REST API, and the README is clear that hotword training must occur online through their web service. That is the sharpest edge in the whole project. Your always-on local trigger depends on a model you had to upload a recording to a third party to get, and the repository ships a sample model, `resources/snowboy.umdl`, for the word snowboy, which is what the example uses.

What the repository contains

The top level of the repository is small, which fits a library that wraps two other libraries. There is an `index.js` entry point, a `lib/` directory with the implementation, a `docs/` directory with the full API documentation at `docs/API.md`, an `examples/` directory, and a `resources/` directory holding the hotword model files. The examples are named for what they show, with an example file, an annyang example and a trigger example, and the repository also links two real projects built with it, a home automation project called L.I.S.A and an ioBroker adapter for Sonus, which tells you the intended audience includes people wiring a microphone into a home automation hub. The `test` script in package.json is `eslint.`, so the test suite is a lint pass rather than unit tests, and the development dependencies list only eslint at version 3.7.0. The project was built with Travis CI and has a Code Climate badge and a DependencyCI badge from that era.

Where this is the wrong choice

The limits are mostly about age and about the dependencies. The first is Snowboy, which is the hotword engine and is pinned to an alpha version, 1.3.1-alpha.1, in the dependencies. A pre-release dependency is a standing risk, and combined with the fact that training must happen through an online web service, the availability of a usable hotword model is outside your control. The second is that the newest release is 1.0.3 from 2019 and the last push was on 2026-09-11, so recent commits exist but no new version has been cut, which usually means the maintenance is compatibility work rather than development. The third is the audio stack. SoX plus a 16 bit PCM recorder plus a native hotword model is a lot of moving parts to install on a device, and a Raspberry Pi with a cheap USB microphone is not a quiet environment for speech detection. The fourth is the design assumption itself. Sonus streams your speech to a cloud recogniser once triggered, which means the audio leaves the device, which is fine for a hobby project and not fine for a product that promises local processing, and the offline half of the promise only covers the hotword.

Editorial conclusion

Sonus suits a maker building a voice interface on a Raspberry Pi or a local machine where the trigger must work without a network round trip, since the hotword detection runs offline and only the recognised speech leaves the device. It is the wrong choice if you need Windows support, since the platform list leaves it unchecked, and the wrong choice if you need a recogniser other than Google Cloud Speech, since the other services are listed but unchecked. Before you build on it, check that the Snowboy hotword model you want still exists, because training is online only and that dependency is the sharpest edge in the project. The last push was on 2026-09-11, the newest release is 1.0.3 from 2019, and the licence is MIT.

Frequently asked questions

Official sources

1. evancohen/sonus on GitHub
2. Issues
3. License: MIT
4. README
5. Releases