Echogarden: a Node.js speech toolset for TTS, Whisper transcription and forced alignment

What Echogarden actually replaces in a Node.js stack

The usual way to do speech work from a Node.js service is to shell out. You install Python, pull in Whisper or Coqui, wrap it in a subprocess, and then spend the next year managing that subprocess. Echogarden's pitch is that this wrapper layer is the product. The README states it is written in TypeScript for the Node.js runtime, runs on Windows (x64, ARM64), macOS (x64, ARM64) and Linux (x64, ARM64), and does not require Python, Docker or other system-level dependencies.

That constraint shapes the engine list. The project says engines are either written in pure TypeScript, ported via WebAssembly, or imported through the ONNX runtime. The npm dependency list backs this up: @echogarden/fvad-wasm, @echogarden/pffft-wasm, @echogarden/icu-segmentation-wasm, @echogarden/flite-wasi, @echogarden/fasttext-wasm. The speech-to-text side includes a custom TypeScript/ONNX port of the OpenAI Whisper architecture alongside whisper.cpp.

The audience is narrow and specific. This is for developers who already ship Node.js and want speech as a library call, not for researchers who need to train models or for teams building a real-time transcription service. The scope is wide: synthesis, recognition, forced alignment, speech translation, language detection, voice activity detection, denoising, source separation and subtitle generation all live in one package. Wide scope in a single package is a trade-off. You get one install and one options surface, but you also inherit every engine's quirks and every engine's model downloads.

How the engine and package system fits together

The architecture has three layers. The CLI and the Node.js API sit on top and are described as closely mirroring each other, which is why CLI flags map onto API options. Below that is a set of engines, listed in docs/Engines.md. Below that is a package system that the README describes as auto-downloading and installing voices, models and other resources as needed.

That third layer is the one that matters operationally. Models are not in the npm tarball. They are fetched on first use, which means the first call to a given engine is slower than the ones after it, and it means an air-gapped machine needs the model cache seeded before anything runs. The README does not document an offline pre-seed command, so if your deployment target has no outbound network access, that is a gap you will have to close yourself.

Engines fall into two groups. Offline engines include Kokoro and VITS for synthesis, eSpeak-NG, and the Whisper ports for recognition, plus RNNoise, NSNet2, MDX-NET, WebRTC VAD and Silero VAD for the audio cleanup tasks. Online engines are cloud services: Google, Microsoft, Amazon, OpenAI and ElevenLabs for synthesis; Google, Microsoft, Amazon and OpenAI for recognition; Google Translate for text translation. The README counts 16 additional engines beyond Kokoro and VITS for synthesis.

Forced alignment deserves its own note because it is the feature that is hardest to get elsewhere without Python. The README describes several variants of dynamic time warping (DTW and DTW-RA), multi-pass hierarchical processing, and a guided decoding mode that uses Whisper recognition models. It claims support for 100+ languages. Alignment output carries word-level timestamps, and the README states word-level timestamps are produced for all recognition, synthesis, alignment and translation outputs. That uniform timestamp model is the strongest design decision in the project, because it means subtitle generation and downstream timing work do not need per-engine special cases.

Installing Echogarden and running a first transcription

The README requires Node.js v18 or later, with v22 or later recommended. Installation is a single global npm install:

npm install -g echogarden@latest

After that, the `echogarden` binary is on your PATH. The README's own samples show the shape of the CLI, and the first one is worth running just to confirm the install and the model download both work:

echogarden speak "Hello World!"

This uses the default synthesis engine. To pin the offline Kokoro engine explicitly, either pass the engine flag or point at a file:

echogarden speak-file story.txt --engine=kokoro

For recognition, the README's example takes an audio file and produces a transcript:

echogarden transcribe speech.mp3

Expect the first run against a new engine to pause while the internal package system downloads the model. Subsequent runs reuse the cache. If you are on npm v12 or later, the README warns that postinstall scripts are disabled by default and that you may need to allow them explicitly, because the `onnxruntime-node` postinstall downloads binaries on some platforms:

npm install -g echogarden@latest --allow-scripts=onnxruntime-node,wtf_wikipedia

Updates use `npm update -g echogarden`, which the README notes may not always move you to the very latest major version. For that, the README points at npm-check-updates and the `ncu -g echogarden` command.

Where Echogarden is the wrong tool

The clearest limitation is streaming. Nothing in the README describes a streaming recognition mode, partial hypotheses, or a socket interface. `echogarden transcribe speech.mp3` takes a file. If you are building live captions or a voice assistant that needs results before the speaker finishes, this is not the library for that job, and no configuration flag will make it one.

The second limitation is deployment weight. The project's selling point is that it avoids Python and Docker, but the npm dependency list is long and includes the AWS SDK clients for Polly and Transcribe streaming, which are pulled in even if you never touch an Amazon engine. The `files` field ships src, dist, data and docs, so the installed package is not small. The absence of Python is real; the absence of a large dependency tree is not.

The third is licence ambiguity in practice. The README says all source code is licensed under the MIT license, and that the package as a whole can be used under the MIT license when GPL licensed libraries like eSpeak-NG are not loaded. package.json declares `"license": "MIT AND GPL-3.0"`, and the repository carries both LICENSE.MIT.md and LICENSE.GPLv3.md. So the effective licence depends on which engines you load at runtime. That is a runtime property, not an install-time one, which makes it easy to miss. If you use eSpeak-NG, you are in GPL territory, and whether that matters depends on how you distribute your software. That is a question for your own legal review, not something the README resolves.

The fourth is API stability. The package is at v3.4.0 with releases at 2026-08-10, 2026-08-30 and 2026-09-08, so the version number moves quickly. The README also points to a release notes file that it says covers releases only up to 1.0.0, which means recent changes are documented through the GitHub release list rather than a maintained changelog. If you pin to a minor version, budget for reading release notes before every bump.

How Echogarden differs from calling Whisper or a cloud API directly

The obvious alternative for transcription is whisper.cpp or the OpenAI API. Both do one thing. whisper.cpp gives you a fast C++ Whisper implementation and nothing else; the OpenAI API gives you hosted recognition with no local model management. Echogarden wraps a TypeScript/ONNX port of Whisper and also exposes whisper.cpp as an engine, then adds alignment, synthesis, translation, VAD, denoising and source separation around it.

The practical difference is what happens after transcription. With whisper.cpp alone, word-level timestamps come from Whisper's own token timing and stop there. Echogarden's alignment path is separate: you can take an existing transcript and an audio file and run DTW-based alignment, or use guided decoding with a Whisper model. The README also lists a speech-to-translated-transcript alignment mode that synchronizes spoken audio in one language to a provided English-translated transcript, and a third mode that takes both a transcript and its translation. Those are workflows you would otherwise assemble from Montreal Forced Aligner or similar Python tooling.

For synthesis, the alternative is a cloud TTS API or a local engine like Piper. Echogarden's offline options are Kokoro and VITS, with cloud engines available as a fallback. The trade-off is model download size and first-call latency against per-character cloud billing. If you synthesize a small amount of text occasionally, a cloud API is simpler. If you synthesize a lot, or need to run without network access, the offline engines are the reason to pick this package.

For voice isolation, the alternative is Demucs, which is a Python project. Echogarden uses the MDX-NET architecture for source separation. If you already have a Python pipeline with Demucs working, there is no reason to move. If you do not want a Python pipeline at all, that is the case Echogarden is built for.

Maintenance, releases and what upgrading costs

The repository is not archived, and the last push was on 2026-09-08. The three most recent releases are v3.4.0 on 2026-09-08, v3.3.0 on 2026-08-30 and v3.2.0 on 2026-08-10. That cadence suggests a project that is being worked on rather than one that has stalled, though the README's release notes file is described as covering releases only up to 1.0.0, so the changelog between 1.0.0 and 3.4.0 lives in the GitHub release list.

The upgrade cost has two parts. The first is the npm update itself. The README notes that `npm update -g echogarden` may not move you to the very latest major version, and suggests npm-check-updates to check and then run the update command it provides. The second part is the model cache. Because the internal package system downloads voices and models on demand, a version bump that changes an engine's model set will trigger new downloads on first use. In a container image, that means either rebuilding with a warm cache or accepting a slow first request after deploy. The README does not document a command to pre-populate the cache, so plan for this as an image-build step you write yourself.

The licence situation is the other ongoing cost. With `"license": "MIT AND GPL-3.0"` in package.json and both licence files in the repository root, the MIT position depends on not loading GPL-licensed libraries such as eSpeak-NG. That means the licence answer is not fixed at install time; it is determined by which engines your code path actually loads. If you are shipping a closed-source product, this is worth resolving before you build on the eSpeak-NG synthesis path, and it is a question for your own counsel rather than something the README settles.

Editorial conclusion

Adopt Echogarden if you are a Node.js developer who wants offline TTS, Whisper-based transcription, forced alignment or voice isolation without installing Python, Docker or platform binaries, and who is comfortable with a GPL-3.0 component in the dependency graph. Do not adopt it if you need streaming recognition with partial results, a frozen API surface, or a licence position that avoids GPL obligations entirely. Before committing, verify three things on your own machine: that your Node version is 18 or later (22 or later is recommended), that npm 12 or later is invoked with --allow-scripts=onnxruntime-node,wtf_wikipedia so the onnxruntime-node postinstall can fetch its binaries, and that the engines you plan to use are actually the ones you expect, since the package mixes offline models with cloud services from Google, Microsoft, Amazon, OpenAI and ElevenLabs.

Frequently asked questions

Official sources

1. echogarden-project/echogarden on GitHub
2. Issues
3. README
4. Releases