PaddleSpeech: the rule-based Chinese frontend, streaming ASR and TTS

Rules run over the text before the acoustic model hears a word

Text goes through a written pipeline before it reaches a vocoder. PaddleSpeech's frontend does Text Normalization, then grapheme-to-phoneme conversion that includes polyphone disambiguation and tone sandhi, plus self-defined linguistic rules for Chinese context. The repository names those two stages in its own paths: the README's text-to-speech sample for the sentence 早上好，今天是2020/10/29，最低温度是-3°C。 is served from a file whose path contains tn_g2p. The date, the negative temperature and the punctuation all have to be rewritten before a phoneme sequence exists.

That layer is the reason to look at this toolkit for Chinese work, and it is also where its boundary sits. Every rule in it was written for Chinese. Cantonese and code-switched Chinese with English both appear as samples in the quick start, and the sample table does not say how much of the frontend each of those samples reuses, so a reader cannot tell from it whether they share one rule table or carry their own. Where a rule is missing or wrong, the failure arrives as a mispronounced syllable rather than a garbled word, which is harder to catch in an audio review than a wrong character in a transcript.

Whisper sits in demos/whisper instead of replacing the staged pipeline

One line in the recent update notes carries the weight: on 2025.09.01 the project added Whisper large v3 and turbo models under demos/whisper. That is the clearest statement in the repository about where this toolkit sits relative to end-to-end speech recognition, which decodes audio straight to text in one multilingual pass.

The rest of PaddleSpeech keeps its stages apart. Punctuation restoration gets its own demonstration in the quick start, with a run of unpunctuated Chinese text on one side and the same text with marks restored on the other, which means a deployable stage rather than a side effect.

The decision that follows is about which failure you can inspect. If a wrong mark in your output matters, a cascaded stage you can read and replace is easier to argue about than a single pass. If you serve many languages and want one model instead of a frontend per language, the Whisper path inside this same repository is the shorter road. Anyone planning to mix the two paths in one service should read demos/whisper rather than assume a common entry point.

setup.py decides the opencc version by asking gcc

The build script shells out to the system compiler and branches on its major version:

    if gcc_version:
        if int(gcc_version.split(".")[0]) < 9:
            return "opencc==1.1.6"  # GCC<9 need opencc==1

The call itself is a subprocess lookup of `gcc --version`, wrapped in a try block that assigns gcc_version to None when it raises. Here is the practical consequence. On a laptop without Command Line Tools installed, or inside a slim container image with no compiler, the lookup fails, the guard is false, and the pin never applies. Your dependency set is then decided somewhere else in a part of setup.py you cannot see from this branch. An install that dies inside opencc or a compiled extension rarely points back at the compiler check, so the person debugging it has to read the build script before suspecting their own environment. A second helper, determine_python_version, returns a string such as '3.7' assembled from sys.version_info.

VERSION = '0.0.0' identifies nothing in a checkout you deploy

Two constants at the top of the root setup.py set the tone for anything you install from source:

VERSION = '0.0.0'
COMMITID = 'none'

These are placeholders for release tooling to overwrite, which means a branch checkout records version 0.0.0 and commit id none. Your pip freeze output, your service logs and your bug reports then carry nothing a maintainer can match to a build. The tags are the only identifiers that survive: r1.5.0, r1.4.2 and r1.4.1 are what you can point at.

The licence has a similar blind spot worth naming. The repository carries an Apache-2.0 LICENSE file covering the code, which is not automatically the licence covering a voice you ship inside a product. That is not legal advice, it is a pointer to the file you have to read yourself before the demo audio becomes a commercial dependency.

One directory per corpus under examples/, and the package is not the whole install

The examples tree holds more than twenty recipe directories: librispeech and ljspeech for English, aishell and csmsc for Chinese, wenetspeech, canton, ami, callcenter, voxceleb, iwslt2012, ted_en_zh and others. Each one is a self-contained recipe, which is the right shape for research and an awkward shape for a shared service, because there is no single config that covers the set.

Look at the top level and the reason becomes clear. Training data preparation lives under dataset/, container images under docker/, the runtime under runtime/, vendored code under third_party/, and helpers under tools/ and utils/, while the importable code sits in paddlespeech/. Model names are collected in the README's Models List section, which the header links to and which is where a reader has to go before picking anything. Linting is configured in the same tree through .clang-format, .flake8, .style.yapf and a .pre-commit-config.yaml, so the style of contributions is machine-checked.

The quick start claims speed and shows no figure for it

The features section promises high-speed and ultra-lightweight models and a production ready streaming ASR and TTS system. The README's opening demonstrations back these claims with sample audio: the recognition examples point at wav files hosted on paddlespeech.cdn.bcebos.com.

A machine without outbound access to that host cannot play those demos. If your decision depends on whether streaming ASR fits inside a per-utterance budget, take two or three candidates from the model list, run each on audio you already own, and keep the numbers yourself.

Last push 2026-08-12 on develop, newest tag from March 2025

The repository is not archived and the default branch is develop, whose last push was on 2026-08-12. The tagged releases run slower: r1.5.0 on 2025-03-05, r1.4.2 on 2024-06-27 and r1.4.1 on 2023-04-14. The gap has a concrete effect, because the Whisper large v3 and turbo addition dated 2025.09.01 landed after r1.5.0 was tagged and exists on the branch rather than in the release.

So installing from the newest tag gives you March 2025 code with no demos/whisper directory, and installing from develop gives you the Whisper path plus a version string of 0.0.0. Neither is wrong, but they are different products and the documentation does not mark the boundary. A team that wants both a stable pin and the current demos has to choose deliberately and record the choice. The README also points at a Gitee mirror and at a documentation site at paddlespeech.readthedocs.io, which hosts further material such as the text-to-speech samples.

Editorial conclusion

PaddleSpeech fits a team that ships Chinese voice features and wants the text frontend visible rather than sealed inside a service. It is the wrong pick if you need one multilingual model for dozens of languages, or if you need latency figures to size a deployment before testing on your own audio. Before adopting it, run one real utterance through the CLI on the branch you intend to pin, and write down which tag you installed, because the newest release tag is r1.5.0 from 2025-03-05 while the default branch has moved since.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. PaddlePaddle/PaddleSpeech on GitHub
3. Project website
4. README
5. Releases