1. 项目缘起：当“行空板”遇上“AI助听器”的构想

最近在捣鼓一块叫“行空板”的开发板，它本质上是一块集成了屏幕、Wi-Fi、蓝牙和各种传感器的微型Linux电脑，特别适合做物联网和AI边缘计算的原型开发。有天晚上，家里老人看电视时又把音量调得震天响，抱怨说有些对白听不清，背景音又太吵。这让我突然想到，市面上的助听器要么价格昂贵，要么功能单一，尤其是对复杂环境下的语音增强和降噪处理得很粗糙。一个念头就冒了出来：能不能用这块功能齐全、又支持Python编程的行空板，结合现在开源的AI语音模型，自己动手做一个智能化的“AI助听器”原型呢？

这个想法听起来有点跨界，但仔细一想，逻辑是通的。行空板有麦克风阵列可以采集声音，有足够的算力（相对单片机而言）来运行轻量级的AI模型，有扬声器或音频接口可以输出处理后的声音，还有屏幕和按键可以交互。而“AI助听器”的核心，无非就是实时采集环境声音，通过AI算法分离出人声、抑制噪声，并对特定频段（通常是老人听力受损的高频部分）进行补偿增强，最后实时播放出来。这不正是边缘AI的典型应用场景吗？它解决的不仅仅是“放大声音”，而是“在嘈杂中听清想听的声音”，这个需求对于听障人士、在嘈杂环境需要清晰沟通的人，甚至只是想要提升会议录音质量的人来说，都很有价值。

所以，这个项目的目的很明确：利用行空板作为硬件载体，探索一条低成本、高灵活度的智能音频处理方案。它不是一个要取代专业医疗设备的产品，而是一个极佳的技术验证平台和学习案例。通过它，我们可以深入理解实时音频流处理、轻量级神经网络在嵌入式设备上的部署、以及如何将AI算法与实际硬件传感器结合的全过程。接下来，我就把自己从零搭建这个原型系统的思路、踩过的坑和最终实现的效果，详细分享一下。

2. 核心硬件选型与行空板能力评估

为什么是行空板？而不是树莓派或者更简单的ESP32？这是项目开始前必须想清楚的问题。我的决策基于以下几个关键点，它们直接决定了项目的可行性和最终体验。

2.1 行空板的独特优势

首先，行空板是一个“All-in-One”的解决方案。我手头的行空板二代，它集成了双核Cortex-A7处理器、512MB RAM、4GB eMMC存储，这些配置跑一个裁剪过的Linux系统和轻量级Python环境绰绰有余。最关键的是其内置的硬件：一个双麦克风阵列、一个2.0英寸的IPS电容触摸屏、多个物理按键、一个RGB LED、还有扬声器插孔。这意味着，我无需额外焊接或连接一堆外设，就能直接获得音频输入（麦克风）、音频输出（扬声器）、人机交互（屏幕和按键）这些核心功能。对于快速原型开发来说，这种集成度极大地降低了硬件调试的复杂度。

其次，它的软件生态对教育和小白开发者友好。行空板默认搭载了基于Debian的定制系统，并预装了完整的Python3环境，以及像numpy,scipy,opencv等常用的科学计算和AI库。更重要的是，官方提供了完善的Python库（unihiker）来控制屏幕、读取传感器、播放声音等，让开发者可以像在电脑上写Python脚本一样操作硬件，而不必深入底层驱动。这对于专注于算法和应用逻辑的我来说，效率提升巨大。

2.2 与替代方案的对比

当然，树莓派Zero 2W或树莓派4B在绝对性能上可能更强，社区资源也更庞大。但树莓派需要额外购买和连接USB声卡、麦克风、屏幕，整个系统会变得臃肿、耗电，且移动性差。而行空板巴掌大的尺寸和内置电池（部分型号支持）的设计，让它更接近一个“设备”而非“开发板”，这对于“助听器”这个需要便携性的概念原型至关重要。

至于ESP32等单片机，虽然功耗极低，但其计算能力和内存（通常只有几百KB RAM）完全无法承载哪怕是最轻量级的神经网络推理。它们更适合做简单的音频采集和传输，而非本地实时AI处理。

2.3 本项目的硬件需求矩阵

我列了一个简单的需求矩阵来验证选型：

评估下来，行空板几乎是“开箱即用”的最佳选择。它唯一的挑战在于，其CPU性能对于复杂的AI模型仍是瓶颈，这就要求我们在算法选型上必须极其考究，专注于“轻量化”和“高效率”。

3. 软件架构与实时音频处理管道设计

确定了硬件，下一步就是设计软件架构。一个实时AI助听器的核心是一个低延迟的音频处理管道（Audio Pipeline）。这个管道需要稳定地、不间断地完成“采集->处理->播放”的循环，任何一环的卡顿都会导致声音断续或可感知的延迟，体验会非常糟糕。

3.1 整体架构图（文字描述）

整个系统可以抽象为以下几个模块：

1. 音频采集模块：利用Python的sounddevice或pyaudio库，从行空板的内置声卡麦克风读取实时音频流。这里的关键参数是采样率（如16000 Hz）和音频块大小（chunk size，如512个样本）。块大小太小会增加处理频率和开销，太大会增加延迟。
2. 环形缓冲区：采集到的音频块会被放入一个先进先出的环形缓冲区。这个缓冲区充当了生产者（采集）和消费者（处理）之间的解耦队列，防止因处理速度偶尔跟不上采集速度而导致数据丢失。
3. AI处理引擎：这是最核心的部分。从缓冲区取出音频块，送入AI模型进行处理。处理任务主要包括：
   • 语音增强/降噪：从带噪音频中分离出干净的语音。
   • 语音频段补偿：根据预设的听力曲线（例如，对高频进行特定增益），对语音频谱进行重塑。
4. 后处理与增益控制：对AI处理后的音频进行必要的平滑、限幅（防止爆音），并应用用户通过屏幕或按键设置的总体增益。
5. 音频播放模块：将最终处理好的音频块，通过sounddevice或pyaudio写入行空板的声卡输出，驱动耳机或扬声器。

整个管道必须在一个独立的线程或进程中运行，以确保不会被UI或其他阻塞操作打断。

3.2 关键挑战：实时性与延迟控制

对于助听设备，延迟必须控制在极低的水平（通常要求低于20毫秒），否则用户会听到自己声音的回声，产生不适感。整个系统的延迟由以下几部分构成：

• 采集延迟：取决于音频块大小。块大小为512样本，在16kHz采样率下，代表512 / 16000 = 0.032秒 = 32毫秒的数据。这是固有延迟。
• 处理延迟：AI模型推理时间。这是最大的变量。
• 播放缓冲延迟：声卡输出缓冲区带来的延迟。

为了降低延迟，我采取了以下措施：

• 减小块大小：尝试使用256甚至128样本的块。但这会显著增加单位时间内的处理次数，对CPU造成更大压力。需要在延迟和CPU负载间权衡。
• 优化模型：选择计算量小的模型，并使用TensorFlow Lite或ONNX Runtime进行推理，它们针对边缘设备有优化。
• 使用多线程：将采集、处理、播放放在不同的线程中，并用高效的队列（如queue.Queue）通信，避免阻塞。

注意：在行空板上，由于CPU性能有限，过小的块大小可能导致处理线程无法及时完成计算，造成缓冲区欠载（播放卡顿）或过载（累积延迟越来越大）。需要通过实测找到一个平衡点。我的经验是，从512样本开始调试比较稳妥。

3.3 代码框架示例

下面是一个极度简化的主循环伪代码，展示了管道的核心逻辑：

import queue import threading import sounddevice as sd import numpy as np # 假设有一个AI处理类 from ai_processor import AIProcessor class AIHearingAid: def __init__(self, chunk=512, sr=16000): self.chunk = chunk self.sr = sr self.audio_queue = queue.Queue(maxsize=10) # 缓冲区 self.processor = AIProcessor() # AI处理实例 self.gain = 1.5 # 用户增益 self.running = False def input_callback(self, indata, frames, time, status): """音频采集回调函数，由sounddevice自动在音频输入线程调用""" if status: print(f"Input error: {status}") # 将音频数据放入队列 # indata是二维numpy数组 (chunk, channels)，我们取单声道 audio_mono = indata[:, 0] try: self.audio_queue.put_nowait(audio_mono.copy()) except queue.Full: pass # 如果队列满了，丢弃最旧的数据？或者直接丢弃新的？这是一个策略问题。通常选择丢弃新的。 def output_callback(self, outdata, frames, time, status): """音频输出回调函数，由sounddevice自动在音频输出线程调用""" if status: print(f"Output error: {status}") try: # 从处理好的队列中取数据 processed_audio = self.processed_queue.get_nowait() except queue.Empty: # 如果没有处理好的数据，输出静音 outdata[:] = 0 return # 应用增益并填充输出缓冲区 outdata[:, 0] = processed_audio * self.gain outdata[:, 1] = processed_audio * self.gain # 假设立体声输出 def process_thread_func(self): """独立的处理线程函数""" while self.running: try: raw_audio = self.audio_queue.get(timeout=0.1) except queue.Empty: continue # AI核心处理：降噪+增强 enhanced_audio = self.processor.inference(raw_audio) # 放入已处理队列，供输出回调读取 try: self.processed_queue.put_nowait(enhanced_audio) except queue.Full: pass # 丢弃处理好的数据，说明播放跟不上 def start(self): self.running = True # 启动处理线程 self.process_thread = threading.Thread(target=self.process_loop) self.process_thread.start() # 创建输入输出音频流 # 注意：这里使用了回调函数，sounddevice会管理自己的线程 self.input_stream = sd.InputStream( channels=1, samplerate=self.sr, blocksize=self.chunk, callback=self.input_callback, device='hw:0,0' # 指定行空板声卡设备 ) self.output_stream = sd.OutputStream( channels=2, samplerate=self.sr, blocksize=self.chunk, callback=self.output_callback, device='hw:0,0' ) with self.input_stream, self.output_stream: print("AI助听器启动...") while self.running: # 这里可以加入UI监听或其他控制逻辑 time.sleep(0.1) def stop(self): self.running = False self.process_thread.join()

这个框架勾勒出了实时处理的核心。其中，AIProcessor类的inference方法是接下来的重点。

4. AI模型选型、轻量化与在行空板上的部署

这是项目的技术核心，也是最大的挑战。我们需要一个能在行空板A7芯片上实时运行（推理时间<30ms）的语音增强模型。

4.1 模型选型考量

完全不用考虑像WaveNet、Transformer这类大型模型。我们的目标是在“效果可接受”和“速度够快”之间找到平衡。目前，适合边缘设备的语音增强模型主要有以下几类：

1. 谱掩码（Spectral Masking）类模型：如经典的RNNoise，或其轻量化变种。这类模型输入是音频的频谱（如梅尔频谱），输出是一个掩码（mask），这个掩码乘以带噪频谱，就能抑制噪声部分。它们模型小，速度快，但音质恢复有时会有点“机械感”。
2. 时域卷积网络（TCN）：如Conv-TasNet的轻量版。直接在时域上操作，分离语音和噪声。效果通常比谱掩码好，但计算量稍大。
3. 微型循环神经网络（Micro RNN）或微型Transformer：一些研究专门为MCU设计的极小模型，参数量可能只有几万到几十万。

经过搜索和测试，我选择了两个方向进行尝试：

• 方向一：使用预训练的轻量级模型。例如，腾讯开源的DFSMN模型，或者一些基于TinyLSTM的降噪模型。这些模型通常已有TensorFlow Lite或ONNX格式，便于部署。
• 方向二：自己训练一个极简模型。如果预训练模型效果或速度不理想，可以考虑用少量数据训练一个超小型UNet或TCN。输入输出都是短时傅里叶变换（STFT）的幅度谱，目标是学习一个谱增益函数。

4.2 模型部署实战：以RNNoise为例

我最终选择先尝试经典的RNNoise，因为它有纯C的实现，效率极高，也有Python绑定。但在行空板上直接编译C代码比较麻烦，更通用的方式是使用其TensorFlow Lite版本。

步骤1：获取TFLite模型可以从开源社区找到已经转换好的RNNoise TFLite模型（.tflite文件）。确保它是适用于实时流式处理的，即输入输出是固定大小的帧。

步骤2：在行空板上部署TFLite运行时行空板默认的Python环境可能没有TFLite解释器。我们需要安装：

# 在行空板的终端中执行 sudo apt update sudo apt install -y python3-pip pip3 install tflite-runtime

注意，要选择与行空板ARM架构兼容的版本。如果pip安装失败，可能需要去TensorFlow官网下载对应的.whl文件进行安装。

步骤3：编写推理封装类

import numpy as np import tflite_runtime.interpreter as tflite class RNNoiseProcessor: def __init__(self, model_path='rnnoise.tflite'): # 加载TFLite模型 self.interpreter = tflite.Interpreter(model_path=model_path) self.interpreter.allocate_tensors() # 获取输入输出详情 self.input_details = self.interpreter.get_input_details() self.output_details = self.interpreter.get_output_details() # 假设模型输入是 [1, 帧长, 特征维度] self.frame_length = self.input_details[0]['shape'][1] self.feature_dim = self.input_details[0]['shape'][2] def extract_features(self, audio_frame): """将一帧时域音频转换为模型所需的特征（如频谱）""" # 这里需要实现与模型训练时一致的特征提取 # 例如计算STFT，取log梅尔频谱等 # 这是一个简化示例 stft = np.abs(np.fft.rfft(audio_frame)) features = np.log(stft + 1e-7).reshape(1, -1) # 可能需要填充或截断以匹配模型输入维度 return features def inference(self, audio_frame): """处理一帧音频，返回增强后的音频帧""" # 1. 特征提取 features = self.extract_features(audio_frame) # 2. 设置输入 self.interpreter.set_tensor(self.input_details[0]['index'], features.astype(np.float32)) # 3. 推理 self.interpreter.invoke() # 4. 获取输出（例如，增强后的频谱或掩码） output_mask = self.interpreter.get_tensor(self.output_details[0]['index']) # 5. 后处理：将掩码应用到原始频谱，再逆变换回时域信号 enhanced_stft = original_stft * output_mask enhanced_frame = np.fft.irfft(enhanced_stft) return enhanced_frame

4.3 性能优化技巧

在行空板上，必须榨干每一分性能：

• 量化：使用TFLite的整数量化（INT8）模型。这能大幅减少模型大小和加速推理，但可能会轻微损失精度。如果模型本身支持量化，效果会很好。
• 使用单精度浮点：如果量化后音质下降太多，退而求其次使用FP32。行空板的CPU对浮点计算有硬件支持，速度尚可。
• 帧重叠处理：为了避免分帧带来的边界效应，通常使用重叠-相加法。但重叠意味着要处理更多数据。需要权衡，比如50%的重叠。
• 利用NumPy向量化：特征提取和后处理中的大量运算（如FFT、矩阵运算）要使用NumPy，避免Python循环。

踩坑实录：我最初使用了一个未经量化的TCN小模型，推理一帧（20ms音频）需要近100ms，导致延迟累积无法实时。后来换用量化的RNNoise变体，推理时间降至8ms左右，整个管道延迟控制在50ms内，虽然仍高于理想值，但已基本可接受。关键教训是：在边缘设备上，模型的第一指标是速度，第二才是精度。

5. 人机交互与功能集成

一个可用的原型，除了核心算法，还需要一个简单的用户界面（UI）来控制和调整参数。行空板的触摸屏和物理按键在这里派上了大用场。

5.1 基于Unihiker库的简易UI设计

行空板官方提供的unihiker库，使得用Python创建GUI变得非常简单。我们可以设计一个极简的界面：

• 中间区域：显示当前音量电平（一个动态的柱状图）。
• 下方滑块：触摸控制整体增益（从0.5倍到3倍）。
• 物理按键：预设模式切换。例如，按键A切换“通用模式”，按键B切换“强降噪模式”（对应不同的AI模型或参数），按键C开关助听器功能。

from unihiker import GUI import time gui = GUI() # 绘制一个增益滑块 gain_slider = gui.draw_slider(x=30, y=180, w=180, h=20, min=0.5, max=3.0, value=1.5, color='blue') # 绘制一个音量电平显示条 level_bar = gui.draw_rectangle(x=30, y=80, w=180, h=20, color='lightgray') fill_bar = gui.draw_rectangle(x=30, y=80, w=10, h=20, color='green') # 初始填充部分 # 定义按键回调函数 def on_key_a_pressed(): global current_mode current_mode = 'general' gui.draw_text(x=20, y=30, text=f'模式: {current_mode}', font_size=12) def on_key_b_pressed(): global current_mode current_mode = 'noise_suppression' gui.draw_text(x=20, y=30, text=f'模式: {current_mode}', font_size=12) # 监听按键事件 gui.on_a_pressed(on_key_a_pressed) gui.on_b_pressed(on_key_b_pressed) # 在主循环中更新UI def update_ui(rms_energy, gain): # 根据音频能量更新电平条长度 bar_width = min(int(rms_energy * 100), 180) fill_bar.config(w=bar_width) # 更新增益显示 gain_text.config(text=f'增益: {gain:.1f}x')

5.2 参数传递与状态管理

UI线程（主线程）和音频处理线程之间需要通信。我们可以使用线程安全的变量或队列。

import threading # 共享状态 shared_state = { 'gain': 1.5, 'mode': 'general', 'is_running': True } lock = threading.Lock() # 在UI回调中修改状态 def on_slider_change(value): with lock: shared_state['gain'] = value # 在音频处理线程中读取状态 def audio_processing_loop(): while shared_state['is_running']: with lock: current_gain = shared_state['gain'] current_mode = shared_state['mode'] # 使用current_gain和current_mode进行相应处理 # ...

5.3 集成所有模块

最终的主程序，需要将音频管道、AI处理器和UI整合在一起，并妥善处理线程间的启动和关闭顺序。一个常见的架构是，主线程负责UI事件循环，音频处理在一个独立线程中运行，两者通过共享状态进行通信。

6. 实测效果、局限性与优化方向

经过一番折腾，原型终于可以运行了。接上行空板的3.5mm耳机，在相对安静的室内，开启降噪和轻度高频补偿后，语音的清晰度有可感知的提升，尤其是对于视频会议中那种常见的压缩音频。在风扇旁测试，背景嗡嗡声被抑制了不少。但是，距离一个“好用”的设备，还有很长的路。

6.1 实测遇到的典型问题

1. 延迟问题：尽管优化后整体延迟在50-80ms左右，但对于听觉极其敏感的用户，尤其是对自己的声音，仍能感觉到轻微的回声感。这主要受限于行空板的CPU能力和音频系统的缓冲设置。
2. 音质损失：轻量级模型在强噪声环境下的处理会带来一定的语音失真，听起来有点“闷”或“电子味”。这是算法保真度与计算资源之间的根本矛盾。
3. 啸叫（Feedback）风险：当输出声音被麦克风再次采集时，会产生刺耳的啸叫。专业助听器有复杂的反馈抑制算法，我们这个简易原型没有，所以在音量开大或麦克风靠近扬声器时会啸叫。
4. 功耗：持续运行AI推理，行空板的耗电可观，如果使用电池，续航可能只有一两个小时。
5. 环境适应性：模型是在特定数据集上训练的，对于训练集中未出现的噪声类型（比如突然的敲门声、键盘声），降噪效果可能不理想，甚至可能误伤语音。

6.2 可行的优化方向

1. 模型层面：
   • 知识蒸馏：用一个大模型（教师）来指导一个小模型（学生）的训练，让小模型在保持小体积的同时获得更好的性能。
   • 神经架构搜索：自动搜索最适合行空板算力约束的微型网络结构。
   • 多模型切换：根据噪声环境（通过一个轻量级分类器判断），动态加载不同的微型处理模型，实现精度和速度的平衡。
2. 工程层面：
   • 利用硬件加速：探索行空板是否有可用的NEON SIMD指令集优化，或者能否调用其GPU进行少量计算（如果支持）。
   • 更精细的音频管道优化：使用更低延迟的音频驱动（如ALSA直接编程），减少系统缓冲。调整块大小和队列深度，找到最佳平衡点。
   • 增加反馈抑制：实现一个简单的自适应滤波器来估计反馈路径并加以抵消。
3. 功能层面：
   • 个性化听力补偿：设计一个简单的听力测试流程（播放不同频率的纯音，让用户反馈是否听到），生成个性化的增益曲线，而非固定提升高频。
   • 方向性增强：利用行空板的双麦克风，实现波束成形，增强正前方声源，抑制侧面和后方噪声。
   • 蓝牙音频支持：增加蓝牙模块，可以将处理后的音频流传输到蓝牙耳机，提升便携性和隐私性。

6.3 项目的真正价值

回过头看，这个“行空板AI助听器”项目，其价值远不止于做出一个能用的设备原型。它更像一个高度集成的边缘AI音频处理实验平台。通过它，我深入走通了从硬件选型、实时系统设计、模型部署与优化到软硬件联调的完整链路。这些经验可以无缝迁移到其他边缘AI音频应用，比如智能语音唤醒、车载噪音消除、对讲机语音增强等等。

对于想要入门边缘AI和实时信号处理的开发者来说，行空板降低了硬件门槛，而“助听器”这个应用场景又极具现实意义和挑战性。它迫使你去思考延迟、功耗、音质这些在实际产品中无法回避的约束条件。虽然最终的原型在性能上无法与商业产品媲美，但整个过程中学到的关于实时性权衡、模型轻量化、嵌入式Python开发的知识，是任何书本都难以完全传授的。

如果你也有一块行空板，并且对AI和音频感兴趣，我非常建议你尝试复现或改进这个项目。可以从最简单的非AI降噪算法（如谱减法）开始，逐步引入更复杂的模型。最重要的不是一步到位做出完美产品，而是在动手的过程中，建立起对“边缘智能”这件事直观而深刻的理解。