C++语音合成入门实战：从零构建TTS引擎核心模块

1次阅读

共计 2717 个字符，预计需要花费 7 分钟才能阅读完成。

现成的语音合成 SDK（比如某度某讯的解决方案）通常存在两个致命问题：

依赖臃肿：动辄需要引入几十 MB 的动态库，对于嵌入式设备极不友好
延迟过高：云端方案网络往返时间经常超过 500ms，本地化方案又占用大量 CPU 资源

最近在开发智能家居项目时，我发现在树莓派上调用商业 TTS 服务会导致设备响应迟钝。于是决定用 C ++ 从头构建一个轻量级语音合成引擎，核心代码不到 2000 行，却能实现 200ms 内的实时语音生成。

测试了三个主流开源 TTS 引擎后，得出如下对比数据：

方案	语音自然度	内存占用	中文支持	API 复杂度
Festival	★★★☆☆	120MB	需插件	高
Mimic	★★★★☆	80MB	内置	中
MaryTTS	★★☆☆☆	200MB+	部分	极高

最终选择 Mimic 作为基础，因为：

采用纯 C 代码便于集成
支持中英文混合合成
提供音高 / 语速实时调整接口

// 典型处理流水线
Text -> [Normalizer] -> [Phonemizer] -> [Prosody] -> [Wavegen] -> PCM

处理中文数字和特殊符号的经典场景：

std::string normalize_text(const std::string_view input) {static const std::wregex cn_number(L"[〇一二三四五六七八九十百千万亿]+");
    std::wstring_convert<std::codecvt_utf8<wchar_t>> converter;

    // UTF- 8 转宽字符处理
    std::wstring text = converter.from_bytes(input.data());

    // 中文数字转阿拉伯数字
    text = std::regex_replace(text, cn_number, [](const std::wsmatch& m) {return chinese_number_to_arabic(m.str());
    });

    // 处理英文缩写
    boost::replace_all(text, L"Dr.", L"Doctor");
    return converter.to_bytes(text);
}

关键点：

使用 codecvt_utf8 保证跨平台编码一致性
宽字符正则匹配避免中文截断问题
静态 regex 对象避免重复编译

template<typename T>
class AudioDoubleBuffer {
    std::array<std::vector<T>, 2> buffers_;
    std::atomic_size_t read_idx_{0};
    std::mutex write_mutex_;

public:
    void push(const T* data, size_t len) {std::lock_guard lock(write_mutex_);
        auto& buf = buffers_[1 - read_idx_];
        buf.assign(data, data + len);
    }

    void swap_buffers() noexcept {read_idx_.store(1 - read_idx_, std::memory_order_release);
    }

    const auto& read_buffer() const noexcept {return buffers_[read_idx_];
    }
};

设计要点：

写操作锁定保证线程安全
原子变量确保读索引切换的可见性
内存序优化避免过度同步

当音频播放线程异常崩溃时，ALSA 设备可能保持锁定状态。解决方案：

class AudioDevice {
    snd_pcm_t* handle_ = nullptr;
public:
    explicit AudioDevice(const char* device = "default") {snd_pcm_open(&handle_, device, SND_PCM_STREAM_PLAYBACK, 0);
    }

    ~AudioDevice() {if(handle_) {snd_pcm_drain(handle_); // 确保缓冲区清空
            snd_pcm_close(handle_);
        }
    }
    // ... 其他方法
};

发现直接加载 30MB 的字典文件会导致启动延迟，改进方案：

使用 mmap 映射字典文件
按需加载常用字库
实现 LRU 缓存最近使用的词条

优化后内存占用从 48MB 降至 12MB，加载时间从 1.2s 缩短到 300ms。

在树莓派 4B（4GB 内存）上的测试结果：

文本长度	合成时间	CPU 占用	内存增量
15 字	86ms	23%	8MB
100 字	320ms	37%	12MB
300 字	820ms	52%	18MB

对比商业 SDK 的 200-400MB 内存占用，自制方案优势明显。

未来可尝试用 ONNX 替换传统 DSP 算法：

// 加载预训练 FastSpeech2 模型
Ort::SessionOptions options;
options.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL);
Ort::Session session(env, "fastspeech2.onnx", options);

// 执行神经网络推理
auto outputs = session.Run(Ort::RunOptions{nullptr},
    input_names.data(), &input_tensor, 1,
    output_names.data(), 1);

这种方案在 x86 平台可获得 5 倍速度提升，但在 ARM 架构需要做针对性优化。

建议的 CMake 工程布局：

tts_engine/
├── include/
│   ├── audio_buffer.hpp
│   └── text_processor.hpp
├── src/
│   ├── wave_generator.cpp
│   └── main.cpp
└── third_party/
    ├── mimic
    └── onnxruntime

完整示例代码已开源在 GitHub（为避免广告嫌疑这里不放链接），关键实现都遵循 RAII 原则，确保资源自动释放。

通过这次开发，发现语音合成领域的几个有趣现象：