树莓派Zero离线语音交互实战：TTS与STT引擎部署与优化

1. 项目概述为什么选择树莓派 Zero 来实现语音功能如果你玩过 Arduino、ESP32 这类微控制器也接触过树莓派 4B 这样的单板电脑那你大概能理解那种“选择困难症”微控制器实时性强、功耗低但算力有限跑个复杂的模型就捉襟见肘单板电脑性能强大、生态丰富但体积和功耗又上去了很多嵌入式场景用起来有点“杀鸡用牛刀”。树莓派 Zero 的出现恰好卡在了这个甜蜜点上。它有着接近微控制器的袖珍尺寸和 GPIO 数量同时又具备运行完整 Linux 系统的能力。这意味着那些在 ESP32 上想都不敢想的 AI 模型比如一些轻量级的语音识别、文本转语音引擎在 Zero 上跑起来居然还挺流畅。给这个小板子加上“说”和“听”的能力瞬间就能打开一大堆好玩又实用的项目大门比如做个能对话的桌面助手、一个离线语音指令控制器或者一个给视障朋友用的语音交互终端。我自己就走过不少弯路。早些年图便宜买过一款宣称支持 Arduino 的国产语音合成模块结果折腾了好几天它确实“说话”了但是一个字母一个字母往外蹦拼出“Hello”要花五秒钟等你听到“o”的时候早就忘了“H”发什么音了体验极其糟糕。这让我下定决心要在真正的计算平台上用成熟的软件方案来实现可靠的语音功能。树莓派 Zero 配合 Linux 上丰富的开源工具链就是一条非常靠谱的路径。接下来我就把自己在 Zero 上实现文本转语音TTS和语音转文本STT的完整过程、踩过的坑以及一些实战心得详细拆解一遍。2. 硬件准备与音频输出配置想让树莓派 Zero “开口说话”第一步不是写代码而是解决硬件上的“哑巴”问题。Zero 板载没有音频输出接口这算是它为了极致紧凑而做的一个牺牲。但别担心我们有多种方法让它“发声”。2.1 音频输出方案选型与实操最直接的方法是使用 HDMI 输出音频。如果你是把 Zero 连接到带扬声器的显示器或电视上使用那么音频会自动通过 HDMI 线缆输出无需额外配置。但很多嵌入式项目需要独立的音频输出这时就需要其他方案。方案一利用 GPIO 引脚输出 I2S 音频这是我最推荐给自制项目的方案成本极低效果不错。树莓派的某些 GPIO 引脚支持复用为 I2S数字音频接口功能。我们通过软件配置就可以让这些引脚输出数字音频信号再接一个便宜的 I2S 音频解码放大模块就能驱动喇叭了。具体操作如下编辑树莓派的配置文件sudo nano /boot/config.txt在文件末尾添加一行配置以使用 GPIO 18 和 13 引脚为例dtoverlayaudremap,pins_18_13这行配置启用了音频重映射并将左右声道分别指定到 GPIO 18 和 GPIO 13。你也可以使用pins_12_13或pins_18_19等组合具体看你的接线方便。保存文件并重启树莓派sudo reboot硬件连接将 GPIO 18左声道、GPIO 13右声道和 GND 引脚连接到一片PAM8403这类 I2S 音频放大模块的对应输入口。模块的输出再接一个 3W 左右的小喇叭。PAM8403 模块在电商平台很容易买到价格通常不到十块钱。注意audremap这个覆盖层overlay可能会因系统版本略有差异。如果重启后没有声音可以尝试将配置改为dtoverlayaudremap,enable1,pins_18_13。更稳妥的方法是查阅你当前使用的树莓派 OS 版本对应的官方文档。方案二使用 USB 声卡如果你有一个闲置的 USB 声卡就是那种非常小的“USB转3.5mm音频”适配器那么这是最“傻瓜式”的方案。直接插到 Zero 的 USB 口可能需要一个 Micro-USB 转 USB-A 的 OTG 转接头系统通常会自动识别并将其设为默认音频输出设备。你可以通过aplay -l命令来查看音频设备列表确认声卡已被识别。方案对比与选择建议GPIO I2S 方案优点是完全利用板载资源无需外接设备集成度高适合最终产品。缺点是配置稍复杂需要焊接或使用排线连接。USB 声卡方案优点是即插即用免驱动适合快速原型验证。缺点是占用一个宝贵的 USB 口Zero 通常只有一个且会多出一小块硬件。对于长期运行、需要集成的项目我强烈推荐 GPIO I2S 方案。它更稳定不依赖外部适配器。PAM8403 模块的驱动能力对于小房间内的语音提示绰绰有余。2.2 麦克风输入方案选择让 Zero “听见”声音同样关键。这里我强烈建议你跳过“折腾”直接选择USB 麦克风。我最初尝试了在创客圈很流行的INMP441一款 I2S 数字麦克风。理论上它的音质更好更“极客”。但在 Zero 上配置它是一场噩梦需要手动编译、加载设备树覆盖层调整内核参数且不同系统版本兼容性差异很大。我花了整整一个周末结果收效甚微驱动时有时无。相比之下一个几十块钱的普通 USB 麦克风我用的就是那种最简单的电脑会议麦克风体验是颠覆性的。插入 Zero 的 USB 口同样可能需要 OTG 转接头系统几乎瞬间就能识别。使用lsusb命令可以看到新设备使用arecord -l可以列出录音设备确认它已就绪。为什么首选 USB 麦克风兼容性无敌Linux 内核自带snd-usb-audio驱动对绝大多数 USB 音频设备即插即用。节省时间省去了复杂的硬件和驱动调试时间让你能快速进入核心的语音应用开发。性能足够对于语音识别和命令采集这种麦克风的信噪比和采样率完全够用。清晰的语音内容远比微弱的硬件指标提升更重要。基础录音测试确认麦克风工作用一个命令就能测试arecord -f S16_LE -r 16000 -d 5 -c 1 test.wav-f S16_LE: 指定录音格式为有符号16位、小端序。这是最通用的 PCM 格式。-r 16000: 采样率设为 16000 Hz。对于语音16kHz 是清晰度和文件大小的甜点很多语音识别引擎也推荐或默认此采样率。-d 5: 录制 5 秒。-c 1: 单声道录音。语音识别通常只需要单声道。test.wav: 输出的文件名。录制完成后用aplay test.wav回放听听效果。如果声音小或杂音大调整麦克风的位置或增益部分 USB 麦克风有物理增益旋钮。在软件端你可以用alsamixer工具调整录音音量。3. 文本转语音TTS引擎的部署与调优硬件通路打通后我们让 Zero 学会“说话”。在 Linux 世界里eSpeak和它的后继者eSpeak-ng是轻量级、离线 TTS 的经典选择。它们可能没有商业引擎那么自然但速度快、资源占用小、支持多语言非常适合嵌入式场景。3.1 安装与初体验在树莓派 Zero 上安装espeak-ng非常简单sudo apt update sudo apt install espeak-ng安装完成后立刻就能在终端里体验espeak-ng Hello, this is Raspberry Pi Zero speaking.你应该能听到一段机械但清晰的英文朗读。这就是基础功能。3.2 核心参数详解与实用技巧espeak-ng的强大在于其丰富的参数可以调整语音的各个方面。1. 语音与语言选择-v参数用于选择声音和语言。例如espeak-ng -v en English default male voice. espeak-ng -v enf2 English female voice 2. espeak-ng -v zh 尝试中文语音。 # 支持中文但效果比较基础 espeak-ng -v de Deutsche Sprache. # 德语使用espeak-ng --voices可以列出所有可用的语音。你会发现它支持非常多的语言变体。2. 调节语速、音高和音量-s语速单词每分钟默认约175。-s 100会慢很多-s 300则像rap。-p音高0-99默认50。-p 90更尖锐-p 10更低沉。-a音量0-200默认100。注意不要设得过高导致破音。一个综合使用的例子espeak-ng -v enf2 -s 120 -p 65 -a 150 A gentle and clear reminder.3. 朗读文件与管道操作除了直接说字符串还能朗读文件内容espeak-ng -f my_script.txt或者结合其他命令实现动态播报。例如播报当前时间date | espeak-ng播报 CPU 温度对监控 Zero 很重要它散热压力大vcgencmd measure_temp | cut -c6- | espeak-ng3.3 集成到 Python 项目在 Python 脚本中调用espeak-ng非常方便使用subprocess模块即可import subprocess def speak(text, voiceen, speed175, pitch50, volume100): 调用 espeak-ng 朗读文本 cmd [ espeak-ng, -v, voice, -s, str(speed), -p, str(pitch), -a, str(volume), text ] try: # 使用 subprocess.run 并丢弃输出避免阻塞 subprocess.run(cmd, stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL, checkTrue) except subprocess.CalledProcessError as e: print(f语音合成失败: {e}) # 使用示例 speak(System initialized successfully.) speak(温度过高请注意散热。, voicezh, speed130)实操心得在循环或频繁调用的场景中要注意subprocess调用的开销。如果语音播报非常频繁可以考虑将其放在一个独立的线程或进程中避免阻塞主程序。另外espeak-ng在合成长文本时会有明显延迟对于实时交互反馈尽量使用短句。4. 离线语音识别STT引擎深度评测与应用让 Zero “听懂”话是更有挑战性也更有趣的部分。在线语音识别如谷歌云需要网络且可能有费用和延迟问题。离线方案才是嵌入式设备的归宿。我重点评测了两款开源离线引擎spchcat和pocketsphinx。4.1 Spchcat高精度但资源消耗大户spchcat是基于 TensorFlow 的语音识别工具识别准确率相对较高支持多达46种语言包括孟加拉语和泰米尔语等印度语言这是一个巨大优势。安装的“骚操作”官方提供的.deb安装包体积巨大约1.2GB且依赖复杂直接在 Zero 上安装几乎必定失败内存和存储都不够。我摸索出一个“曲线救国”的方法在性能更强的树莓派 4B 或 X86 电脑上操作将 Zero 的 TF 卡插入读卡器连接到树莓派 4B 上启动或者直接在树莓派 4B 的系统中操作。在强性能设备上下载并安装在树莓派 4B 上下载spchcat的.deb包并安装。这个过程会解压和部署大量模型文件耗时可能超过20分钟。移植回 Zero安装完成后关闭树莓派 4B将 TF 卡插回 Zero。由于安装过程只是在文件系统里放置了可执行文件和模型而 Linux 系统是兼容的因此spchcat可以在 Zero 上直接运行。基本使用与实战技巧识别音频文件spchcat your_audio.wav它会将识别结果直接输出到终端。识别系统声音例如转录正在播放的视频spchcat --sourcesystem这个功能非常酷可以用来做实时字幕生成。指定语言spchcat --languageen_US my_audio.wav保存结果到文件spchcat lecture.wav transcript.txtPython 集成示例import subprocess import tempfile def transcribe_with_spchcat(audio_file_path): 使用 spchcat 识别音频文件 cmd [spchcat, audio_file_path] try: result subprocess.run(cmd, capture_outputTrue, textTrue, checkTrue, timeout60) # 设置超时 return result.stdout.strip() except subprocess.TimeoutExpired: return 错误识别超时音频可能过长或模型未响应。 except subprocess.CalledProcessError as e: return f识别过程出错: {e.stderr} def record_and_transcribe(duration10, sample_rate16000): 录制一段音频并识别 with tempfile.NamedTemporaryFile(suffix.wav, deleteFalse) as tmpfile: audio_path tmpfile.name # 录制 record_cmd [arecord, -f, S16_LE, -r, str(sample_rate), -d, str(duration), -c, 1, audio_path] subprocess.run(record_cmd, checkTrue) print(f录制完成: {audio_path}) # 识别 text transcribe_with_spchcat(audio_path) print(f识别结果: {text}) # 清理临时文件可选 # import os; os.unlink(audio_path) return text # 使用示例 if __name__ __main__: # 识别现有文件 # result transcribe_with_spchcat(test.wav) # print(result) # 录制并识别 transcript record_and_transcribe(duration5)重要警告spchcat在 Zero 上运行时 CPU 负载极高温度上升很快必须安装散热片。长时间运行时务必监控温度vcgencmd measure_temp。我实测下来处理超过3-4分钟的音频文件Zero 就会开始明显降频识别速度变慢。因此它更适合处理短语音指令或间隔性的识别任务。4.2 Pocketsphinx轻量快速的备选方案如果你被spchcat的资源要求劝退或者需要更快的响应速度牺牲一些准确率那么pocketsphinx是经典选择。它由卡内基梅隆大学开发非常轻量。安装与配置安装比spchcat简单得多sudo apt update sudo apt install pocketsphinx pocketsphinx-en-us python3-pocketsphinx如果需要其他语言模型可以搜索安装类似pocketsphinx-zh-cn中文的包。Python 集成实时语音识别pocketsphinx的 Python 接口用起来很直观可以实现实时监听from pocketsphinx import LiveSpeech def live_listen(): 实时监听麦克风并识别 print(开始监听... (按 CtrlC 停止)) # 可配置参数 speech LiveSpeech( verboseFalse, # 关闭详细日志 sampling_rate16000, # 采样率与录音设置匹配 buffer_size2048, # 缓冲区大小 no_searchFalse, full_uttFalse, # lmFalse, # 如果不使用语言模型使用声学模型 # dicpath/to/custom.dic # 自定义词典 ) for phrase in speech: recognized_text str(phrase) print(f你说: {recognized_text}) # 在这里添加你的处理逻辑例如 if hello in recognized_text.lower(): print(-- 触发问候响应) elif stop in recognized_text.lower(): print(-- 停止监听) break if __name__ __main__: try: live_listen() except KeyboardInterrupt: print(\n监听已停止。)Python 集成识别音频文件from pocketsphinx import AudioFile def transcribe_file_pocketsphinx(audio_file_path): 使用 pocketsphinx 识别音频文件 config { verbose: False, audio_file: audio_file_path, buffer_size: 2048, no_search: False, full_utt: False, } transcription [] for phrase in AudioFile(**config): transcription.append(str(phrase)) return .join(transcription) # 使用示例 # text transcribe_file_pocketsphinx(command.wav) # print(text)4.3 双引擎对比与选型建议经过大量测试我对两款引擎的优缺点总结如下特性SpchcatPocketsphinx识别准确率较高对清晰语音和常见词汇识别好一般对环境噪音和口音更敏感资源消耗极高CPU持续满载发热严重很低CPU占用率通常低于30%响应速度较慢尤其是长音频很快适合实时指令语言支持极广46种对小语种友好较少主流几种安装复杂度非常复杂需要“移植安装”简单apt直接安装适用场景离线转录短篇清晰演讲、录制好的音频分析实时语音指令控制、关键词唤醒、低功耗持续监听选型心法追求最佳识别率且处理任务非连续比如每天转录几次会议纪要选spchcat。务必做好散热。追求实时性和低功耗比如做一个语音控制的智能开关需要7x24小时待命选pocketsphinx。一个折中的架构在资源允许的情况下可以两者结合。用pocketsphinx做始终在线的关键词唤醒例如“嗨小派”唤醒后再启动spchcat来识别后续更复杂的指令语句。这样既保证了低功耗待机又能在需要时提供高精度识别。5. 完整项目实战构建一个离线语音交互终端理论说再多不如动手做一个。我们来整合前面所有知识在树莓派 Zero 上打造一个简单的离线语音交互终端。这个终端能听、能说并能根据简单的语音命令执行操作比如报时、报温度、控制 GPIO。5.1 系统架构设计监听循环使用pocketsphinx持续监听麦克风等待唤醒词例如“小派小派”。指令识别被唤醒后切换到一个更精确的识别模式可以仍是pocketsphinx或尝试短时启用spchcat捕获用户指令。指令解析将识别出的文本与预定义的命令列表进行匹配。任务执行执行对应操作如调用系统命令、控制 GPIO。语音反馈使用espeak-ng给出操作结果的语音反馈。5.2 核心代码实现以下是这个终端的一个简化版核心代码框架#!/usr/bin/env python3 import subprocess import time from pocketsphinx import LiveSpeech import RPi.GPIO as GPIO # 如果需要控制GPIO # GPIO 初始化示例控制一个LED LED_PIN 17 GPIO.setmode(GPIO.BCM) GPIO.setup(LED_PIN, GPIO.OUT) GPIO.output(LED_PIN, GPIO.LOW) def speak(text): 语音合成函数 subprocess.run([espeak-ng, -v, enf2, -s, 150, text], stdoutsubprocess.DEVNULL, stderrsubprocess.DEVNULL) def get_cpu_temp(): 获取CPU温度 output subprocess.check_output([vcgencmd, measure_temp]).decode(utf-8) temp output.strip().replace(temp, ).replace(C, ) return temp def execute_command(command_text): 解析并执行命令 cmd_lower command_text.lower() response if time in cmd_lower: # 报时 from datetime import datetime current_time datetime.now().strftime(%H:%M) response fThe time is {current_time} elif temperature in cmd_lower or temp in cmd_lower: # 报温度 temp get_cpu_temp() response fCPU temperature is {temp} degrees Celsius. elif light on in cmd_lower or turn on in cmd_lower: # 开灯 GPIO.output(LED_PIN, GPIO.HIGH) response Light is turned on. elif light off in cmd_lower or turn off in cmd_lower: # 关灯 GPIO.output(LED_PIN, GPIO.LOW) response Light is turned off. elif hello in cmd_lower: response Hello there! How can I help you? elif goodbye in cmd_lower or exit in cmd_lower: response Goodbye! speak(response) return False # 返回False表示退出循环 else: response Sorry, I didnt understand that command. return response def main(): wake_word hey pi print(f语音终端已启动。唤醒词是 {wake_word}。) speak(System ready. Waiting for your command.) # 第一阶段唤醒词监听 # 这里简化处理实际应用中唤醒词检测需要更精细的配置 print(正在监听唤醒词...) for phrase in LiveSpeech(verboseFalse, sampling_rate16000, keyphrasewake_word, kws_threshold1e-20): # 当检测到唤醒词时phrase会是一个特殊对象这里简化逻辑 print(f唤醒词检测到) speak(Yes?) # 第二阶段指令监听短暂时间窗口 print(请说出指令...) # 重新配置LiveSpeech不使用关键词进行全句识别持续几秒 # 注意这是一个简化的实现。更健壮的做法是使用线程或异步来管理超时。 start_time time.time() listen_timeout 5 # 监听5秒 instruction for utterance in LiveSpeech(verboseFalse, sampling_rate16000, no_searchFalse, full_uttFalse): instruction str(utterance) if instruction: print(f识别到指令: {instruction}) break if time.time() - start_time listen_timeout: print(指令监听超时。) speak(I didnt hear a command.) break if instruction: # 执行指令 result execute_command(instruction) if result is False: # 收到退出命令 break if result: print(f系统回复: {result}) speak(result) print(返回唤醒词监听模式...\n) GPIO.cleanup() print(程序退出。) if __name__ __main__: try: main() except KeyboardInterrupt: print(\n用户中断。) GPIO.cleanup()代码要点与避坑指南唤醒词检测上述代码中keyphrase和kws_threshold参数用于pocketsphinx的关键词搜索模式。kws_threshold值需要反复调试值越小越敏感但也更容易误触发。实际项目中可能需要一个独立的、配置更优化的唤醒词检测循环。指令监听超时我们的设计是唤醒后开启一个5秒的窗口来接收指令。这个逻辑比较简单在嘈杂环境中可能不稳定。更高级的做法是使用 VAD语音活动检测来判断用户何时开始和结束说话。GPIO 操作记得在程序退出前用GPIO.cleanup()清理引脚状态这是一个好习惯。错误处理生产环境中需要对subprocess调用、GPIO 操作等添加更完善的异常捕获和日志记录。5.3 项目优化与扩展思路这个基础终端可以朝多个方向扩展增加本地问答能力集成一个轻量级的本地 NLP 库如Rasa NLU或自定义的意图识别脚本让它能理解更复杂的句子比如“客厅的灯调亮一点”。结合在线服务需网络在识别出复杂问题后例如“今天天气如何”通过网络请求调用免费的天气 API获取数据后再用 TTS 播报。这样就在离线核心功能上增加了智能扩展。做成语音日志记录仪定时录制环境声音用spchcat转录成文字保存到日志文件中。可以用于记录会议、讲座要点。为视障者提供辅助结合摄像头和物体识别模型如用 MobileNet SSD做成一个“视觉语音助手”识别到面前的物体后用语音说出来。“这是一个红色的杯子在你正前方大约一米处。”6. 性能调优、散热与稳定性保障在 Zero 上跑语音 AI性能和散热是绕不开的坎。下面是一些确保项目稳定运行的实战经验。6.1 监控与降温措施必须监控温度Zero 的 CPU 在满负荷运行spchcat时几分钟内就能突破 70°C。长期高温会缩短设备寿命并导致降频。命令行监控vcgencmd measure_temp。可以写个脚本定期记录。简易散热方案一定要贴散热片选择那种带粘胶的铝合金散热片直接贴在 Zero 的 CPU 芯片上。效果立竿见影通常能降低 10-15°C。主动散热可选如果外壳密闭或环境温度高可以考虑加一个超小的 5V 风扇从 GPIO 取电但要注意风扇本身的噪音可能被麦克风拾取。6.2 系统性能调优关闭图形界面如果你的项目是纯语音交互不需要桌面。在系统配置中直接启用控制台启动sudo raspi-config-System Options-Boot / Auto Login-Console可以节省大量内存和 CPU 资源。调整交换空间Zero 内存小512MB容易爆。适当增加交换文件swap大小可以防止程序因内存不足崩溃但会加速 TF 卡损耗。谨慎使用。sudo dphys-swapfile swapoff sudo nano /etc/dphys-swapfile # 修改 CONF_SWAPSIZE1024 (单位MB) sudo dphys-swapfile setup sudo dphys-swapfile swapon使用性能更好的 TF 卡语音识别涉及大量小文件读写模型加载、音频缓存。一张 Class 10 或 A1/A2 级别的高速 TF 卡能显著提升响应速度。6.3 音频质量提升技巧识别准确度极度依赖录音质量。采样率与格式对于语音16kHz、单声道、16位 PCMS16_LE是最佳平衡点。更高的采样率对识别提升有限但会大幅增加计算量和文件大小。环境降噪软件上可以使用sox工具进行简单的降噪处理。物理上选择指向性好的麦克风并为其制作一个简单的海绵防风罩能有效降低环境噪音。增益调整使用alsamixer调整麦克风增益确保录音波形饱满但不过载在arecord测试时观察波形不要出现“削顶”的平直线。6.4 常见问题排查速查表问题现象可能原因排查步骤与解决方案没有声音输出1. 音频输出未正确配置。2. 音量被静音或调至最低。3. 喇叭或放大器故障。1. 检查/boot/config.txt中dtoverlay配置是否正确并重启。2. 运行alsamixer确保主音量和PCM音量未静音MM表示静音按M键解除。3. 用aplay /usr/share/sounds/alsa/Front_Center.wav测试系统音效。麦克风无法录音1. 麦克风未正确识别。2. 默认录音设备错误。3. 麦克风硬件故障。1. 运行arecord -l查看设备列表。确认 USB 麦克风在列。2. 创建或修改~/.asoundrc文件指定默认设备。或在使用arecord时通过-D hw:1,0指定设备设备号从arecord -l获取。3. 换一个 USB 口或麦克风测试。spchcat运行报错或卡死1. 内存不足。2. 模型文件损坏或路径不对。3. CPU 过热降频。1. 用free -h查看内存。确保关闭不必要的进程。2. 检查spchcat是否通过“移植法”正确安装。尝试在树莓派 4B 上运行测试。3. 安装散热片监控温度。考虑将任务拆分避免处理过长音频。pocketsphinx识别率极低1. 环境噪音过大。2. 麦克风音质差或增益不当。3. 未使用合适的语言模型。1. 改善录音环境使用指向性麦克风。2. 用arecord录制测试文件并用aplay回放确保人声清晰。3. 确认安装了正确的语言包如pocketsphinx-en-us。对于特定领域词汇可以考虑训练自定义语言模型。语音播报有杂音或破音1.espeak-ng音量 (-a) 设置过高。2. 放大器增益过高。3. 电源供电不足。1. 将-a参数降至 80-120 范围试试。2. 调整 PAM8403 模块上的增益电阻如果可调或降低输入信号强度。3. 确保 Zero 使用足额 5V/2A 电源音频部分单独供电或使用质量好的电源。折腾树莓派 Zero 的语音功能就像是在给一个沉默的精灵赋予听觉和嗓音。从最初的硬件选型、驱动调试到后来的引擎对比、项目集成每一步都充满了探索的乐趣和踩坑的“收获”。最终当你对着这个小板子说句话它能清晰地回答你或者准确执行你的指令时那种成就感是实实在在的。我个人最深的体会是在资源受限的设备上做 AI 应用“妥协”和“权衡”是核心艺术。没有完美的方案只有最适合当前场景的选择。是追求spchcat的准确度而忍受它的高热和慢速还是选择pocketsphinx的轻快而接受其偶尔的“耳背”这完全取决于你的项目是需要转录讲座还是控制智能灯。同样USB 麦克风带来的便捷性远胜于为了那一点理论上的音质提升而去死磕 I2S 麦克风驱动。最后一个小技巧在部署最终项目时考虑将espeak-ng的语音数据缓存到内存盘tmpfs中可以略微提升首次语音播报的响应速度。虽然提升可能只有零点几秒但在交互体验上这种细节的优化往往能带来质的不同。语音交互的未来是离线的、本地的、低功耗的而树莓派 Zero 这样的平台正是实现这个未来的绝佳试验场。