最近在做一个智能家居项目时，需要让ASR-Pro语音模块实时播报传感器数据。本以为是个简单的任务，结果发现实时性总是不理想，播报延迟经常超过500ms。经过两周的折腾，终于把延迟压到了50ms以内，这里把踩坑经验分享给大家。

一、为什么会有延迟？

1. 硬件瓶颈：ASR-Pro默认的DMA缓冲区大小是1KB，按16kHz采样率计算，单次传输就需要62.5ms
2. 端点检测迟疑：为了防止误触发，模块默认设置300ms的静音检测窗口
3. 协议栈开销：天问平台的数据包需要经过TCP/IP协议栈，每个环节都会增加几毫秒延迟

二、三种采集方案实测对比

测试环境：STM32F407 + ASR-Pro模块，采样率16kHz

• 轮询方式
• 优点：实现简单

• 缺点：CPU占用率高达70%，延迟波动大（40-120ms）

• 中断驱动

• 优点：延迟稳定在30ms左右

• 缺点：高频中断影响其他外设

• 双缓冲DMA（最终方案）

• 优点：延迟20ms，CPU占用<15%
• 缺点：需要精细管理内存

三、核心代码实现

关键配置宏定义（放在config.h中）：

#define SAMPLE_RATE     16000  // 16kHz采样
#define DMA_BUF_SIZE    320    // 20ms音频块(16bit samples)
#define CRC_POLYNOMIAL  0x1021 // CCITT标准

音频流初始化代码片段：

void init_audio_stream(void) {
    tw_audio_config_t cfg = {
        .sample_rate = SAMPLE_RATE,
        .channel = 1,
        .format = TW_AUDIO_FORMAT_PCM16,
        .dma_buf_size = DMA_BUF_SIZE
    };

    // 注册回调函数
    tw_audio_stream_init(&cfg, dma_callback);

    // 启用硬件CRC校验
    HAL_CRC_Init(&hcrc);
}

// DMA传输完成回调
void dma_callback(uint8_t *buf, uint32_t len) {
    uint16_t crc = HAL_CRC_Calculate(&hcrc, (uint32_t*)buf, len/2);

    // 添加CRC头后发送
    tw_audio_send_packet(buf, len, crc);
}

四、必须掌握的优化技巧

1. FFT窗口选择
2. 256点窗口：识别延迟12ms，但低频分辨率差
3. 512点窗口（推荐）：平衡点，延迟25ms

4. 1024点窗口：识别准但延迟超50ms

5. RTOS任务优先级设置

6. 音频采集任务：优先级4（高于默认任务）
7. 网络传输任务：优先级3

8. GUI任务：优先级2

9. 麦克风阵列的坑

10. 间距要大于4cm避免相位抵消
11. 推荐使用ECM麦克风而非MEMS

五、遇到网络抖动怎么办？

1. 实现简单的重传协议：

   #define MAX_RETRY 2
   
   void send_with_retry(uint8_t *data) {
       int retry = 0;
       while(!tw_send(data) && retry++ < MAX_RETRY) {
           osDelay(5); // 等待网络恢复
       }
   }

2. 在本地缓存最近3秒的音频，遇到丢包时降采样补发

六、进阶玩法建议

可以结合天问的语义分析API，实现这样的智能响应： - 当用户说"当前温度"时，自动播报"客厅25℃，卧室23℃" - 检测到用户说"太冷了"，自动调高空调温度

最后放一张实测的延迟数据截图，可以看到优化后平均延迟控制在48ms左右：

折腾这一圈最大的体会是：实时系统里没有银弹，必须根据具体场景在延迟、准确率和资源消耗之间找到平衡点。建议大家在开发时先用Saleae逻辑分析仪抓取时间线，找准瓶颈再针对性优化。