RHVoice stores statistical models instead of recordings, and its newest tag is six months behind the branch

The trade between footprint and naturalness is stated, not implied

Most synthesizers describe what they can do. This one describes what it gives up. RHVoice uses statistical parametric synthesis and relies on existing open-source speech technology, mainly HTS and related software. Voices are built from recordings of natural speech, and the reason they have small footprints is stated plainly: only statistical models are stored on a user's computer, not the audio. The cost is named in the same paragraph, namely that these voices lack the naturalness of synthesizers which generate speech by combining segments of the recordings themselves. What is claimed instead is that they remain very intelligible and resemble the speakers who recorded the source material. That is an unusual shape for a project page, because the quality ceiling and the storage advantage come from the same design decision, and a reader is told about both before being told anything about configuration.

Adding a language is a data problem, not a code problem

The project began speaking only Russian and now supports ten more: American and Scottish English, Brazilian Portuguese, Esperanto, Georgian, Ukrainian, Kyrgyz, Tatar, Macedonian, Albanian and Polish. The stated condition for going further is the interesting sentence. In theory it is possible to implement support for other languages if all the necessary resources can be found or created. That phrasing puts the constraint on voice data rather than on the synthesiser, which follows from the design: a voice is a statistical model estimated from recordings, so what a new language needs is recorded speech and the estimation work, not a new engine. The list itself also shows the project's centre of gravity without saying so, with four of the ten being languages that have no widely available commercial voice at all. Russian remains the first entry in the history sentence, and the current version line is still numbered 1.x.

It ships an NVDA driver instead of waiting for one

Compatibility with platform text-to-speech interfaces is the ordinary integration story, and RHVoice handles it in the ordinary way: SAPI5 on Windows, Speech Dispatcher on GNU/Linux, and Android's own text-to-speech APIs. The screen reader case is the exception, and it is worth separating out. RHVoice can be used by the NVDA screen reader directly, and the reason it can is that the driver is provided by RHVoice itself rather than written by the screen reader's project. That is a deeper commitment than being callable: somebody maintains a driver, tracks its compatibility and ships it in the same release as the engine. It also explains why the project's voice quality matters more than a novelty would, since an intelligibility problem in a statistical voice is an accessibility problem the moment that path is used. The unofficial Matrix room and the IRC channel are the places that kind of integration gets discussed.

Two platforms have packages and Linux is the build-it-yourself one

Installation is described per platform and the three paths are not equivalent. Windows has prebuilt binaries, made available through the documentation rather than through a package manager. GNU/Linux gets building instructions and a packaging status section in the documentation, which is the wording of a project that knows distro packaging is partly done by other people. Android is the only platform with a real store listing, through F-Droid or Google Play, under the package identifier com.github.olga_yakovleva.rhvoice.android. There is also a hosted demonstration service linked from the page for listening to an example without installing anything, though it lives on a third-party domain rather than on the project site. The documentation itself is published in English, Russian and Ukrainian, three index files under separate language directories, and the mailing list is Russian-language while GitHub Discussions carries the general traffic.

Two build systems, a submodule, and an iOS release lane

The root of the repository carries more build machinery than a synthesiser strictly needs. There is a CMakeLists.txt with a cmake/ directory, and there is an SConstruct with a site_scons/ directory, so the project can be configured by two different build systems and neither has replaced the other. A .gitmodules file sits beside an external/ directory, so part of the build tree arrives as submodules rather than as tracked source. Then there are the release lanes: a fastlane/ directory, which is iOS release automation, and a snap/ directory, both of which name platforms the documentation does not list as supported. Neither the README nor the platform list mentions an iOS target, so a fastlane configuration is either dormant or aimed at work the page has not described. Licensing is handled in the same two-track style, with a LICENSE.md for the code and a separate file for the Apple App Store.

Weekly patch tags in March, then half a year without one

The three most recent releases are 1.18.2, 1.18.3 and 1.18.4, published on 2026-03-11, 2026-03-19 and 2026-03-31, so within a single week the project shipped three patch versions and then stopped tagging. The default branch was pushed to on 2026-09-28, roughly six months after the newest tag. Both facts matter and they point in opposite directions. The patch cadence inside that week is the behaviour of a project actively fixing voices, which is what a statistical synthesiser needs most, since a model trained on one speaker's recordings has a narrow range of inputs before it falls apart. The gap afterwards is the behaviour of a project whose day to day work happens somewhere other than release tagging, so anyone building against master is running code that no published release has ever described.

Editorial conclusion

RHVoice is worth a look wherever intelligibility matters more than naturalness and disk space matters more than fidelity: screen reader output, a kiosk, a low bandwidth terminal, a language with no commercial voice. Three things to check before committing. Read the naturalness sentence as the project's own limit and audition the voices for your text rather than trusting the label, because the intelligibility claim and the naturalness claim are separate. Confirm your platform is actually supported in the way you need, since Windows and Android have packages and Linux is a build from source. And note that the three most recent tags are all from one week in March 2026 while the branch has moved since, so pin to a release rather than to master if reproducibility matters.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. RHVoice/RHVoice on GitHub