ECHO: an Electron music player that puts the audio path, not the UI, in the middle
The Bit-Perfect Bridge to Your Sonic Multiverse.
At a glance
- What is it?
- ECHO is a desktop player for a local music library, built as an Electron shell with a typed IPC bridge, a SQLite library and a native audio host, with a community edition under AGPL and a commercial edition on Steam. This looks at the architecture, the output paths, and where the split between editions matters.
- Who is it for?
- ECHO fits a Windows or macOS listener with a large local library who wants a player that shows the codec, sample rate and output device and offers bit-perfect output paths, and it fits a team that wants to extend a player with wallpapers, visualisers and lyrics scenes. It does not fit someone who streams from a Subsonic or Navidrome server as the primary source, and it is the wrong choice if you cannot accept a native host component per platform.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The library is the product, not the transport
ECHO is a desktop music player for a local library, and the readme's framing is that the library is the main event: it is a player born for local music, taking each track seriously and each playback seriously. The project tagline is a promise about audio fidelity rather than about features, calling itself the bit-perfect bridge to your sonic multiverse.
The feature table at the end of the readme is the clearest statement of scope. For listening to your own music, it offers a local library, album and artist browsing, playlists, dynamic lyrics and play history. For choosing an output, it offers the system output, WASAPI in shared and exclusive mode, and ASIO, so you can connect headphones, speakers or an external DAC. For seeing the sound chain, it shows the encoding, the sample rate, the output device and the processing state at a glance. And for changing the atmosphere, there are themes, visualisers, wallpaper integration and workshop items.
The readme also stresses responsibility for the signal path: the Audio Core and the native host are responsible for real playback state, and the output mode, device capability and the reason for a fallback are all traceable, while the interface is responsible for presentation and for giving every switch a definite result.
That is the design statement, and it is the thing to evaluate. A player that tells you it fell back to a shared-mode device because the exclusive mode was unavailable is doing something quite different from one that silently changes your output.
Renderer, typed IPC bridge, Electron main, and a native host
The architecture document linked from the readme badges is the source for the layering, and the badges themselves summarise it: the interface is React and TypeScript, the bridge is typed IPC, the main process is Electron, the library is SQLite, and the audio is an Audio Core plus a native host.
That is a five-part split, and each part has a job. The React renderer draws the interface. The typed IPC bridge is the contract between the renderer and the rest of the application, and making that contract typed is what stops a renderer bug from becoming an undefined behaviour in the audio path. The Electron main process owns the application lifecycle. SQLite stores the library, which is the right choice for a local collection of tens of thousands of tracks that has to be scanned, indexed and queried. And the native host owns the actual playback, where the real-time work happens.
The native part is not a detail in this project, and the repository layout shows how much of it there is. There is a `native/` directory, an `asio-test-native/` directory, `build-resources/`, `integrations/`, and a `scripts/` directory that is mostly about building and verifying native components. The `package.json` scripts are named after that work: `build:audio-host`, `build:audio-component`, `build:src-cuda-worker`, `build:taskbar-host`, and `build:taskbar-thumbnail-helper`, with matching `ensure:` scripts that verify the pieces are present before a dev run.
So the answer to the question of how ECHO claims bit-perfect output is visible in the structure: the sample-accurate work happens in a native host, and the interface does not get a vote in it.
The three editions are three different products
ECHO ships in three forms, and the readme is careful to separate them, because they differ in more than the feature list.
The community edition is permanently free and open source under AGPL v3, and the readme says the project is maintained by everyone's participation, with the player distributed through GitHub Releases. The Steam edition is described as going further along the same local listening experience, with more complete optimisation, more features and better performance, and it adds auto update, cloud sync of some settings, achievements, friends status and the Steam workshop. The Steam build is the one shown in the readme screenshots, which the readme notes explicitly.
The third is the Android edition, in a separate repository, a native Android music player supporting local and remote libraries, dynamic lyrics and sound adjustment, and it can pair with the desktop app over Echo Link: browse the computer's library on the phone, remote control desktop playback, or stream computer music to the phone. The pairing requires both devices on the same local network, the desktop side running a build that supports Echo Link, and a full pairing link for the first authorisation, with the exact features depending on the versions at both ends.
For an evaluator, the split matters in one specific way. The open repository is the community edition, and the things a reviewer would want to check, the workshop content, the cloud sync, the auto updater, are in the paid build. The open source part is a working player, not the whole product.
The Steam workshop is worth a mention on its own, because it turns the player into a platform. The readme shows a workshop item called ECHO Code that arranges lyric following, playback progress, audio stream information and a live spectrum into an interactive terminal panel, and the repository ships a Web wallpaper example so that wallpaper creators can start from a working scene.
Building the shell needs Electron, Node 22 and a pile of native checks
The `package.json` describes the current code base as the ECHO Next Phase 0 desktop music app shell, named `echo-next`, at version 26.10.7, and it is a private package with an `out/main/index.js` entry and an ES module `type`.
The toolchain pins are strict. The engines field requires Node `>=22.23.0 <23` with npm `>=10 <11`, and Volta pins the same versions, Node 22.23.1 and npm 10.8.2, with npm 10.8.2 as the package manager. The repository also carries `.node-version`, `.nvmrc` and `flake.nix` with `shell.nix` and `package.nix`, so there is a Nix path for the environment as well as the Node version managers.
The dev script shows what it takes to run the thing locally:
node scripts/ensure-native-abi.mjs electron && node scripts/ensure-airplay-raop.mjs && node scripts/ensure-dev-audio-runtime.mjs && node scripts/ensure-audio-host.mjs && node scripts/ensure-smtc-host.mjs && node scripts/ensure-taskbar-host.mjs && node scripts/build-taskbar-thumbnail-helper.mjs && electron-vite devSix verification steps and one build step run before the dev server starts. Each `ensure` script checks that a native component is present and correct for the current environment, and the ABI check is there because a native module compiled against the wrong Electron ABI will fail at load time rather than at build time.
The `dev:full` script is the same chain with two differences, using `build-smtc-host.mjs` where the dev variant uses `ensure-smtc-host.mjs`, and it exists because the full path rebuilds the SMTC host rather than only checking it. There is also a separate `build:audio-host:release` script that adds a `--require-cuda` flag, and a `build:src-cuda-worker` script, so the release build has a CUDA path that the development build does not need.
Testing is Vitest, with `vitest.config.ts` at the root, and the `test/` directory alongside an `asio-test-native/` directory for the ASIO specific tests.
Where ECHO is the wrong tool
Four limits are worth stating.
The first is the source of the music. This is a player for a local library, and the local library is the centre of the design. The repository topics include Subsonic and Navidrome, which tells you the remote server is part of the vocabulary, but the readme's own framing, the screenshots of 16,813 tracks across 1,856 albums, the library scan and metadata handling, and the whole feature table are about local music. If your library lives on a server and you want the server's catalogue, you are outside what the documentation describes.
The second is the platform shape of the native host. There is a Windows taskbar host, a taskbar thumbnail helper, an SMTC host for the Windows media session, a macOS runtime with its own prepare and verify scripts, and a CUDA path for the release build. Each of those is a per-platform component that has to exist, has to be versioned with the rest, and has to be right on the user's machine. That is the cost of the fidelity claim, and it is a real cost for a team that has to support more than one platform.
The third is ASIO. ASIO is a vendor-specific interface, and the fact that the repository has a dedicated `asio-test-native/` directory shows how much of the audio path is tied to it. That is a feature for the target audience and a portability question for everyone else.
The fourth is maturity and the shape of the open source part. The manifest describes the desktop app as a Phase 0 shell, the release history lists a single recent tag, 26.10.7 on 2026-10-07, and the last push to the repository was on 2026-10-19. The readme also asks you to fix problems, improve features, documentation and translations, which is the language of a project asking for help rather than one shipping a settled product.
AGPL-3.0-only, with third party code keeping its own terms
The licence section is precise. Copyright is 2026 Moekotori, and code, documentation and materials in this repository that are owned by the project and not otherwise licensed are under the GNU Affero General Public License v3.0, spelled as AGPL-3.0-only in both the readme and the package manifest. Third party components, dependencies, fonts, media tools and SDKs keep their own licences, which is the usual arrangement for a project of this size.
The AGPL choice is worth a thought for a desktop application. The network copyleft trigger matters for a server, and ECHO is a local player, so the practical effect for a user is the ordinary one: you can read, modify and redistribute the code, and if you run a modified version as a service over a network you owe the source to the people who use it. For a fork that wants to ship a modified build as a hosted service, that is the term to read first.
The project also keeps the rest of the standard paperwork in the tree, with `LICENSE` and an `AGENTS.md` for tooling support, and separate `README.md` and `README_EN.md` files with the English version linked from the Chinese one, and documentation published under `docs/` and at echonext.moe.
For the record on the maintenance side, the last push was on 2026-10-19 and the newest release, 26.10.7, was published on 2026-10-07, so the project is moving, and the versioning scheme with the year and month in the number suggests a release roughly per month with patch numbers.
Editorial conclusion
ECHO fits a Windows or macOS listener with a large local library who wants a player that shows the codec, sample rate and output device and offers bit-perfect output paths, and it fits a team that wants to extend a player with wallpapers, visualisers and lyrics scenes. It does not fit someone who streams from a Subsonic or Navidrome server as the primary source, and it is the wrong choice if you cannot accept a native host component per platform. Before you commit, read the architecture document at `docs/ECHO_NEXT_ARCHITECTURE.md`, check that the AGPL-3.0-only terms on the community edition are what you want, and note that the desktop package is described in its own manifest as a Phase 0 app shell.
Frequently asked questions
How do I get ECHO the music player?
The community edition is free and open source under AGPL v3 and is distributed through GitHub Releases. A Steam edition with auto update, cloud sync of some settings, achievements, friends status and the workshop is sold separately, and an Android player is published from the separate echoandroid repository.
What output modes does ECHO support?
The feature table lists the system output, WASAPI in shared and exclusive mode, and ASIO, for connecting headphones, speakers and external DACs. The interface shows the encoding, the sample rate, the output device and the processing state, and the native host records the output mode, device capability and the reason for any fallback.
What does the ECHO architecture look like?
The badges and the architecture document describe a React and TypeScript renderer, a typed IPC bridge, an Electron main process, a SQLite library store, and an Audio Core plus native host for playback. The native host owns real playback state while the interface is responsible for presentation.
How do I build ECHO from source?
The dev script runs a chain of native component checks, including the native ABI check, the AirPlay RAOP setup, the dev audio runtime, the audio host, the SMTC host and the taskbar host, then starts electron-vite. The manifest requires Node 22.23.0 or newer with npm 10, and there is a Nix flake for the environment.
Can ECHO play music from my phone or control the desktop player?
The separate Android edition can, over Echo Link. With the phone and the computer on the same local network, a desktop build that supports Echo Link running, and a full pairing link for the first authorisation, you can browse the computer library on the phone, control desktop playback, or stream computer music to the phone. The available features depend on the versions at both ends.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/moekotori-echo)Was this useful?