简介基于ESP32与ICS-43434数字麦克风、MAX98357 I2S功放实现的无线对讲机完整源码面向物联网硬件开发者、电子爱好者和Python程序员适用于校园、户外、小型团队等无需基站即可语音通信的场景。压缩包共29个文件约14.57MB核心为14个Python脚本涵盖主控逻辑、Wi-Fi通信、音频采集与播放、外设驱动按钮/触摸/电位器等模块另含5个WAV测试音频、2份PDF芯片手册、JSON配置及辅助文件便于对照硬件调试。已有989人学习/下载。源码结构清晰包含main.py、wifihandler、dispatcher、ics43434、max98357a等关键模块并附有验证脚本与说明文档开发者可直接烧录运行也可基于模块化设计二次开发快速构建低成本的无线语音传输系统。1. 两片ESP32加两套I2S外设无线对讲机的核心难点在“流”不在“响”两片ESP32开发板各接一只ICS-43434数字麦克风再各接一只MAX98357功放和小喇叭不依赖云端、不需要额外基站就能在同一个Wi-Fi网络里组成一对可通话的无线对讲机。把麦克风、功放、ESP32三大件凑齐并不难真正让新手卡壳的是ICS-43434输出的是I2S数字音频流MAX98357吃进去的也是I2S数字音频流中间的ESP32既要消化DMA缓冲区的采集节奏又要控制UDP包的网络发送节奏两边节奏一旦错位声音就会断断续续或是延迟飙升。这个设计本质上不是“把声音发出去”而是“把音频当流水一样持续搬运”适合已经会用ESP32点灯、读传感器想往实时音频方向走一步的嵌入式工程师。下面的方案全部围绕真实可跑通的最小系统展开先从I2S链路说起。2. 搭建I2S音频链路ICS-43434与MAX98357的接线、驱动与数据格式2.1 引脚规划两组I2S外设还是共用一条总线ESP32 芯片内部通常有两组 I2S 外设在 Arduino-ESP32 环境里分别暴露为I2S_NUM_0和I2S_NUM_1。这里建议把麦克风和功放分开挂到两组外设上I2S0 只做接收RX采集 ICS-43434I2S1 只做发送TX驱动 MAX98357。虽然 ESP32 的 I2S 也支持全双工模式但把两个方向混在同一组外设上调试时钟极性时容易互相干扰尤其是在采样率较高的情况下。接线时主要区分两类引脚BCLK位时钟和 WS/LRC字选择。ICS-43434 的 WS 引脚需要硬件配置为 I2S 模式有的模块例如 Adafruit 的 ICS-43434 分线板已经通过上拉电阻固定直接接信号即可。MAX98357 的 LRC 引脚在 I2S 标准模式下与 WS 同义只是名称不同而已。数据引脚方面ICS-43434 输出引脚标记为SDMAX98357 的输入标记为DIN两者名字不同但本质都是数据线。下面是这套设计中我常用的一组引脚分配供参考。注意 GPIO 编号因开发板型号不同会有变化凡是标着“开发板丝印”的以你手里的板子丝印为准。功能外设设备BCLKWS/LRCDATA麦克风采集I2S0 (RX)ICS-43434GPIO26GPIO25GPIO22功放播放I2S1 (TX)MAX98357GPIO32GPIO33GPIO27按键PTT可选GPIO/GND按钮--GPIO5提示ICS-43434 的供电电压范围标称是 1.6V 到 3.6V可以直接使用 ESP32 的 3.3V 供电MAX98357 供电范围是 2.5V 到 5.5V用 3.3V 时扬声器输出功率会低于 5V 供电但对讲机场景下音量通常够用。2.2 采样率、位深与 DMA 缓冲的取舍对讲机语音信号的频率范围通常只需要覆盖 300Hz 到 3.4kHz所以 8kHz 采样率在理论上就足够。但实际工程中我一般会选 16kHz 采样率原因有两个一是 16kHz 时 WS 引脚翻转频率更高接收端对时钟边沿的采样容错更好二是后期如果要加简单的噪声抑制算法16kHz 的频域信息比 8kHz 丰富得多。位深这里有一个容易踩的坑。ICS-43434 内部 ADC 输出的是 24 位数据左对齐在 32 位帧里而 MAX98357 可以接收 16 位或 32 位的 I2S 数据。如果直接把 24 位数据交给 MAX98357音量会偏小且低字节全是无意义数据。所以在代码里要统一用 16 位输出从 DAC 读取数据后右移 8 位把高 16 位保存下来再写入 TX 外设。这样做还有一个额外好处——每包传输的数据量减半网络负载更小。DMA 缓冲区大小直接决定延迟和美声度。ESP32 的 I2S 驱动使用环形 DMA 缓冲区常见的配置是buffer_count8、buffer_len256也就是每块缓冲区可存放 256 个 32 位样本I2S_DAC 模式下总共约 8 块。缓冲区越小延迟越低但如果采集和网络发送的速度不匹配很容易产生 underrun播放端数据取空或 overrun采集端数据溢出。实际调参时建议先跑通默认配置不要一上来就追求低延迟。2.3 Arduino 框架下的 I2S 驱动最小代码使用 Arduino-ESP32 内核自带的 I2S 库可以直接省略厂商 SDK 的初始化细节下面是两个外设初始化的代码。注意i2s_pin_config_t结构体里的变量名在不同内核版本中略有差异相对稳定的写法如下。#include driver/i2s.h // I2S0 采集 ICS-43434 数字麦克风 void i2s_mic_init() { i2s_config_t i2s_rx_config { .mode (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_RX), .sample_rate 16000, .bits_per_sample I2S_BITS_PER_SAMPLE_32BIT, // 读 32 位左对齐实际取高 16 位 .channel_format I2S_CHANNEL_FMT_ONLY_LEFT, .communication_format I2S_COMM_FORMAT_STAND_I2S, .intr_alloc_flags ESP_INTR_FLAG_LEVEL1, .dma_buf_count 8, .dma_buf_len 256, .use_apll false, .tx_desc_auto_clear false, .fixed_mclk 0 }; i2s_pin_config_t pin_rx { .bck_io_num 26, .ws_io_num 25, .data_out_num -1, .data_in_num 22 }; i2s_driver_install(I2S_NUM_0, i2s_rx_config, 0, NULL); i2s_set_pin(I2S_NUM_0, pin_rx); }// I2S1 播放到 MAX98357 功放 void i2s_speaker_init() { i2s_config_t i2s_tx_config { .mode (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_TX), .sample_rate 16000, .bits_per_sample I2S_BITS_PER_SAMPLE_32BIT, // 写入 32 位帧有效数据放高 16 位 .channel_format I2S_CHANNEL_FMT_ONLY_LEFT, .communication_format I2S_COMM_FORMAT_STAND_I2S, .intr_alloc_flags ESP_INTR_FLAG_LEVEL1, .dma_buf_count 8, .dma_buf_len 256, .use_apll false, .tx_desc_auto_clear true, // TX 下应开启避免 DMA 残留数据刷杂音 .fixed_mclk 0 }; i2s_pin_config_t pin_tx { .bck_io_num 32, .ws_io_num 33, .data_out_num 27, .data_in_num -1 }; i2s_driver_install(I2S_NUM_1, i2s_tx_config, 0, NULL); i2s_set_pin(I2S_NUM_1, pin_tx); }上面的配置里两个关键参数需要重点说明。bits_per_sample I2S_BITS_PER_SAMPLE_32BIT表示的是 I2S 总线上传输的帧位宽而不是有效音频位深。ICS-43434 的数据左对齐到 32 位读取后手动右移 8 位得到 16 位有效数据写入 MAX98357 时再把 16 位数据左移 8 位放回 32 位帧中。tx_desc_auto_clear这个参数在 TX 模式下建议置为true否则 DMA 描述符里残留的旧数据会在无新数据可写时被重复播放产生刺耳杂音。初始化完成后可以先用一个最简单的本地回环做验证从 I2S0 读出数据处理成 16 位再写入 I2S1。如果扬声器能听到自己说话的回声不接网络说明整条音频通路已经打通。void loop() { int32_t sample[512]; size_t bytes_read 0; size_t bytes_written 0; int16_t out[512]; esp_err_t err i2s_read(I2S_NUM_0, sample, sizeof(sample), bytes_read, portMAX_DELAY); if (err ESP_OK bytes_read 0) { int cnt bytes_read / 4; // 32 位样本个数 for (int i 0; i cnt; i) { out[i] (int16_t)(sample[i] 14); // 右移 8 位取高 16 位再放大 2 倍补偿音量 } i2s_write(I2S_NUM_1, out, cnt * 2, bytes_written, portMAX_DELAY); } }这里采样值右移 14 位而不是 8 位是一个实际调试中的经验值ICS-43434 在正常说话音量下的输出幅值远小于满量程单纯右移 8 位获得的数据会明显偏小听感音量过低。右移 14 位相当于在取出高 16 位的基础上额外乘了 2 倍属于一个粗糙的固定增益补偿。真实产品里应该用 AGC 或者软音量控制但在原型验证阶段这个补偿很有用。3. 无线传输链路用 UDP 承载 20ms 一包的语音流3.1 为什么对讲机场景必须选 UDP 而不是 TCP对讲机音频对实时性的要求远高于可靠性。TCP 为了保证数据完整会在丢包后重传已经错过时间窗口的数据包这些包到达播放端时已经“过期”播放出来就是一顿一顿的噪音同时 TCP 的拥塞控制会把延迟抖动进一步放大。UDP 没有重传丢包最多造成一个短促的间隙听感上往往只像一个字被切掉一点远比重传引发的卡顿易接受。在局域网环境下UDP 丢包率本身很低所以更不用担心可靠性问题。常见做法是两个 ESP32 直连同一个路由器或者其中一个 ESP32 开 SoftAP、另一个以 STA 模式连接。UDP 单播即可满足点对点通话如果后续要做一呼多响的群组对讲改成广播地址并让接收端过滤特定端口的数据就能实现代码改动很小。这里的“无线链路”方案不依赖任何外网服务所有数据都在本地局域网内转发。3.2 包长、发送节奏与抖动缓冲区的下限选定 16kHz、16 位单声道后码率是固定的每秒 32000 字节。音频要打包成 UDP 数据报发送包长直接决定发送频率和延迟上限。我一般选择 20ms 为一个音频帧即每包 640 字节。20ms 是语音通信行业里普遍认可的一个平衡点包太短如 5ms会导致每秒发包 200 个Wi-Fi 的节能模式和路由器的转发能力都吃紧包太长如 100ms虽然网络效率高但明显感觉说话有拖沓感。这里有一组计算可以直观感受带宽占用。每包音频负载 640 字节加上 UDP 头 8 字节、IP 头 20 字节链路层实际约 670 字节左右每秒 50 包合计不足 300kbps。对于 Wi-Fi 的链路速度而言非常充裕。接收端要注意抖动缓冲区的设计。UDP 包从发送端到接收端并不是严格等间隔到达的Wi-Fi 的 beacon 间隔、路由器调度都会造成抖动。接收端用 ESP32 的 I2S DMA 缓冲本身就能吸收一部分抖动所以不一定要额外实现 FIFO 队列当 I2S 写数据的速度略快于 UDP 包到达速度时DMA 缓冲会自然填补间隙直至 underrun。如果测试中发现频繁出现断音优先增大dma_buf_count而不是急于实现应用层队列。3.3 发送端与接收端的 UDP 音频代码实现这里用 Arduino 的WiFiUdp库实现发送和接收。发送端放在 loop 里读取 20ms 音频后直接beginPacket发出。#include WiFi.h #include WiFiUdp.h WiFiUDP udp; IPAddress peerIP(192, 168, 1, 200); // 对端 ESP32 的 IP const uint16_t PORT 50001; // 读取 20ms 音频并发送 void send_audio_packet() { int16_t pcm[320]; // 20ms * 16kHz 320 个样本 size_t bytes_read 0; esp_err_t err i2s_read(I2S_NUM_0, pcm, sizeof(pcm), bytes_read, pdMS_TO_TICKS(50)); if (err ! ESP_OK || bytes_read 0) { return; } int bytes_to_send (bytes_read / 4) * 2; // 32 位转 16 位后的字节数 // 发送前手动把每个 32 位样本的高 16 位提取出来 // 这里为简化演示已假设 pcm 缓冲区预先做过缩放转换 udp.beginPacket(peerIP, PORT); udp.write((const uint8_t *)pcm, bytes_to_send); udp.endPacket(); } void loop() { send_audio_packet(); delay(5); // 适当等待避免阻塞 I2S 读操作 }这段代码有一个隐含的关键点i2s_read请求读sizeof(pcm)也就是 640 字节在 16kHz、32 位帧格式下正好对应 20ms 音频。pdMS_TO_TICKS(50)作为超时避免 I2S 数据不足时无限阻塞整个网络处理。如果改用portMAX_DELAY在 DMA 缓冲为空时 loop 会停滞可能导致 UDP 接收端无法及时处理入站数据包。接收端代码更短核心是parsePacket读取网络数据后直接i2s_writevoid recv_audio_packet() { int packet_size udp.parsePacket(); if (packet_size 0) { return; } uint8_t buf[700]; int len udp.read(buf, sizeof(buf)); if (len 0) { return; } // 将 16 位 PCM 数据左移回 32 位帧高位 int16_t *pcm (int16_t *)buf; int sample_cnt len / 2; int32_t frame[700]; for (int i 0; i sample_cnt; i) { frame[i] ((int32_t)pcm[i]) 14; // 与发送端右移量保持一致 } size_t bytes_written 0; i2s_write(I2S_NUM_1, frame, sample_cnt * 4, bytes_written, pdMS_TO_TICKS(50)); }接收端注意buf大小要留足余量700 字节对 640 字节的音频包加 UDP/IP 头绰绰有余。i2s_write前的移位操作是为了把 16 位数据还原成 32 位帧结构。如果你在初始化时配置了I2S_BITS_PER_SAMPLE_16BIT就不需要这个移位步骤但前面说过 16 位帧格式下 ICS-43434 的 24 位数据会被截断音质损失明显所以两端的帧位宽必须和收发数据的格式完全一致。4. 双侧对称工作把采集、发送、接收、播放排成任务4.1 半双工 PTT 还是全双工模式无线对讲机最常见的交互是半双工按住按钮说话松开按钮收听。半双工的好处不只是符合使用习惯更重要的是从根源上避免了回声问题——本地扬声器播放的声音不会在麦克风采集时被误发出去。代码上PTT 按键只需要作为发送流程的使能条件松开时不读取 I2S 麦克风数据即可。全双工模式不需要按键两边的 ESP32 同时执行采集发送和接收播放。这在技术上是可行的因为 I2S0 与 I2S1 是相互独立的 DMA 通道Wi-Fi 协议栈也支持并发收发。但全双工打开后本地扬声器的声音会直接灌进本地麦克风形成强回声。如果要做全双工必须叠加回声抑制算法否则体验远不如半双工。建议第一版直接做半双工。原型验证全双工链路是否通可以用 5.2 提到的 ducking 方案临时压制回声而不是一开始就上自适应滤波器。4.2 FreeRTOS 任务切分与优先级设置即使 loop 里同时写发送和接收逻辑也能工作但音频处理和网络收包一旦互相阻塞延迟就会抖动。更稳定的做法是把两件事拆成独立任务并指定运行核心。ESP32 是双核 MCUI2S 读取和 UDP 收发都涉及外设中断与 DMA把它们放到不同核心上可以减少调度冲突。下面是一个典型的任务分配方式// 发送任务采集 - UDP 发送 void task_send(void *param) { while (1) { if (ptt_pressed()) // 读取 GPIO5 { send_audio_packet(); } delay(2); } } // 接收任务UDP 接收 - I2S 播放 void task_recv(void *param) { while (1) { recv_audio_packet(); delay(1); } } void setup_wireless_tasks() { xTaskCreatePinnedToCore(task_send, send_task, 8192, NULL, 2, NULL, 1); xTaskCreatePinnedToCore(task_recv, recv_task, 8192, NULL, 2, NULL, 0); }优先级选 2 是经验值高于loopTaskArduino 的默认任务优先级通常是 1低于 Wi-Fi 协议栈内部任务通常在 3 到 5 之间。这样既保证音频任务能抢占低优先级的串口打印等逻辑又不会干扰 Wi-Fi 驱动的底层收发。任务栈大小 8192 字节也值得注意WiFiUdp库内部缓冲区较大栈给得太小会直接复位重启。4.3 链路验证方法从正弦波到语音接入真实人声之前先用正弦波验证整条数据通路。发送端循环生成一个 1kHz 正弦波并把数据送进 UDP 发送函数接收端把收到的数据同时写成串口波形。没有逻辑分析仪时可以在接收端串口里每隔一定字节打印当前样本值看到规律性变化的数值就说明链路是通的。还有一种强有力的验证方式是本地环回测试在发送端代码里同时初始化 I2S0 和 I2S1然后通过 UDP 把采集到的音频先发送到对端对端再原样转发回来播放。这个方案同时验证了两个板的采集、无线收发、播放全链路比各自单独测试更接近真实工作状态。5. 延迟预算、回音抑制与一个可复用的测延迟技巧5.1 40ms 延迟预算怎么分配对讲机可接受的端到端延迟一般是 100ms 以内但我建议按 40ms 作为设计目标。其中采集端 I2S DMA 缓冲约 8msUDP 发送等待和调度约 5msWi-Fi 空中传输约 1 到 3ms接收端 DMA 缓冲约 8ms剩下的约 16ms 留给任务调度抖动。这个预算下即使路由器在 beacon 间隙出现 10ms 级别的抖动整体仍在 60ms 以内通话感很自然。压缩这个延迟的关键在于减少 DMA 缓冲区大小但减少缓冲区意味着 underrun 风险增加。一个实测有效的做法是把dma_buf_count从 8 降到 4同时把dma_buf_len降到 128然后连续通话几分钟观察是否有爆音。如果没有就再进一步如果出现爆音说明接收端播放速度高于网络供给速度需要回退一档。5.2 全双工下最简单的回声抑制ducking全双工模式下一个直观但非常有效的回声压制方法是音量衰减当本端检测到麦克风有语音输入时立刻把扬声器播放音量压低。这个技术叫 ducking通话系统中常用于压低背景音乐在对讲机全双工场景下同样适用。float speaker_gain 1.0f; // 在接收任务里写入 I2S 前应用增益 void apply_speaker_gain(int32_t *frame, int cnt, float gain) { for (int i 0; i cnt; i) { frame[i] (int32_t)(frame[i] * gain); } }检测麦克风语音能量的代码很简单每 10ms 统计一次当前缓冲区的峰值绝对值超过某个阈值就判定为“本端在说话”此时将speaker_gain快速拉低到 0.15当能量低于阈值持续 100ms 后再恢复为 1.0。这个策略能显著减轻“自己听到自己回声”的感觉并不能完全消除但成本几乎为零不占用额外 CPU。5.3 环回测延迟法不算绝对时间也能得到单向延迟双向对讲时很难精确测量单向延迟因为你无法同时让两端以同一时钟计时。这里有一个很实用的环回技巧发送端 A 发一个带时间戳标记的 UDP 包给接收端 BB 收到后不做任何处理立即把同一包原样发回 A。A 测量从发出到收到回包的时间差除以 2就得到端到端的单向延迟。// A 端发送测试包并计算往返时间 unsigned long t_start millis(); udp.beginPacket(peerIP, PORT); udp.write((const uint8_t *)PING, 4); udp.endPacket(); while (millis() - t_start 1000) { if (udp.parsePacket() 0) { unsigned long rtt millis() - t_start; Serial.printf(单程延迟约 %lu ms\n, rtt / 2); break; } } // B 端收到任何数据包都原样回发 int len udp.parsePacket(); if (len 0) { udp.read(buf, sizeof(buf)); udp.beginPacket(udp.remoteIP(), udp.remotePort()); udp.write(buf, len); udp.endPacket(); }这个测试包含的是 Wi-Fi 空中的双向传输时间物理链路上是同一跳所以除以 2 得到的是“点到点单向延迟”I2S 采集和播放的缓冲延迟不包含在内。实际对讲时的感知延迟还要再加上两端 DMA 缓冲的时间所以测量值通常比人耳感知值低一些。调试时只要这个测量值稳定在 15ms 以内说明网络侧没有瓶颈后续优化的重点应该放在 I2S DMA 配置上。本文还有配套的精品资源点击获取 ESP32无线对讲机设计：I2S音频采集与UDP传输的实时链路搭建
简介基于ESP32与ICS-43434数字麦克风、MAX98357 I2S功放实现的无线对讲机完整源码面向物联网硬件开发者、电子爱好者和Python程序员适用于校园、户外、小型团队等无需基站即可语音通信的场景。压缩包共29个文件约14.57MB核心为14个Python脚本涵盖主控逻辑、Wi-Fi通信、音频采集与播放、外设驱动按钮/触摸/电位器等模块另含5个WAV测试音频、2份PDF芯片手册、JSON配置及辅助文件便于对照硬件调试。已有989人学习/下载。源码结构清晰包含main.py、wifihandler、dispatcher、ics43434、max98357a等关键模块并附有验证脚本与说明文档开发者可直接烧录运行也可基于模块化设计二次开发快速构建低成本的无线语音传输系统。1. 两片ESP32加两套I2S外设无线对讲机的核心难点在“流”不在“响”两片ESP32开发板各接一只ICS-43434数字麦克风再各接一只MAX98357功放和小喇叭不依赖云端、不需要额外基站就能在同一个Wi-Fi网络里组成一对可通话的无线对讲机。把麦克风、功放、ESP32三大件凑齐并不难真正让新手卡壳的是ICS-43434输出的是I2S数字音频流MAX98357吃进去的也是I2S数字音频流中间的ESP32既要消化DMA缓冲区的采集节奏又要控制UDP包的网络发送节奏两边节奏一旦错位声音就会断断续续或是延迟飙升。这个设计本质上不是“把声音发出去”而是“把音频当流水一样持续搬运”适合已经会用ESP32点灯、读传感器想往实时音频方向走一步的嵌入式工程师。下面的方案全部围绕真实可跑通的最小系统展开先从I2S链路说起。2. 搭建I2S音频链路ICS-43434与MAX98357的接线、驱动与数据格式2.1 引脚规划两组I2S外设还是共用一条总线ESP32 芯片内部通常有两组 I2S 外设在 Arduino-ESP32 环境里分别暴露为I2S_NUM_0和I2S_NUM_1。这里建议把麦克风和功放分开挂到两组外设上I2S0 只做接收RX采集 ICS-43434I2S1 只做发送TX驱动 MAX98357。虽然 ESP32 的 I2S 也支持全双工模式但把两个方向混在同一组外设上调试时钟极性时容易互相干扰尤其是在采样率较高的情况下。接线时主要区分两类引脚BCLK位时钟和 WS/LRC字选择。ICS-43434 的 WS 引脚需要硬件配置为 I2S 模式有的模块例如 Adafruit 的 ICS-43434 分线板已经通过上拉电阻固定直接接信号即可。MAX98357 的 LRC 引脚在 I2S 标准模式下与 WS 同义只是名称不同而已。数据引脚方面ICS-43434 输出引脚标记为SDMAX98357 的输入标记为DIN两者名字不同但本质都是数据线。下面是这套设计中我常用的一组引脚分配供参考。注意 GPIO 编号因开发板型号不同会有变化凡是标着“开发板丝印”的以你手里的板子丝印为准。功能外设设备BCLKWS/LRCDATA麦克风采集I2S0 (RX)ICS-43434GPIO26GPIO25GPIO22功放播放I2S1 (TX)MAX98357GPIO32GPIO33GPIO27按键PTT可选GPIO/GND按钮--GPIO5提示ICS-43434 的供电电压范围标称是 1.6V 到 3.6V可以直接使用 ESP32 的 3.3V 供电MAX98357 供电范围是 2.5V 到 5.5V用 3.3V 时扬声器输出功率会低于 5V 供电但对讲机场景下音量通常够用。2.2 采样率、位深与 DMA 缓冲的取舍对讲机语音信号的频率范围通常只需要覆盖 300Hz 到 3.4kHz所以 8kHz 采样率在理论上就足够。但实际工程中我一般会选 16kHz 采样率原因有两个一是 16kHz 时 WS 引脚翻转频率更高接收端对时钟边沿的采样容错更好二是后期如果要加简单的噪声抑制算法16kHz 的频域信息比 8kHz 丰富得多。位深这里有一个容易踩的坑。ICS-43434 内部 ADC 输出的是 24 位数据左对齐在 32 位帧里而 MAX98357 可以接收 16 位或 32 位的 I2S 数据。如果直接把 24 位数据交给 MAX98357音量会偏小且低字节全是无意义数据。所以在代码里要统一用 16 位输出从 DAC 读取数据后右移 8 位把高 16 位保存下来再写入 TX 外设。这样做还有一个额外好处——每包传输的数据量减半网络负载更小。DMA 缓冲区大小直接决定延迟和美声度。ESP32 的 I2S 驱动使用环形 DMA 缓冲区常见的配置是buffer_count8、buffer_len256也就是每块缓冲区可存放 256 个 32 位样本I2S_DAC 模式下总共约 8 块。缓冲区越小延迟越低但如果采集和网络发送的速度不匹配很容易产生 underrun播放端数据取空或 overrun采集端数据溢出。实际调参时建议先跑通默认配置不要一上来就追求低延迟。2.3 Arduino 框架下的 I2S 驱动最小代码使用 Arduino-ESP32 内核自带的 I2S 库可以直接省略厂商 SDK 的初始化细节下面是两个外设初始化的代码。注意i2s_pin_config_t结构体里的变量名在不同内核版本中略有差异相对稳定的写法如下。#include driver/i2s.h // I2S0 采集 ICS-43434 数字麦克风 void i2s_mic_init() { i2s_config_t i2s_rx_config { .mode (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_RX), .sample_rate 16000, .bits_per_sample I2S_BITS_PER_SAMPLE_32BIT, // 读 32 位左对齐实际取高 16 位 .channel_format I2S_CHANNEL_FMT_ONLY_LEFT, .communication_format I2S_COMM_FORMAT_STAND_I2S, .intr_alloc_flags ESP_INTR_FLAG_LEVEL1, .dma_buf_count 8, .dma_buf_len 256, .use_apll false, .tx_desc_auto_clear false, .fixed_mclk 0 }; i2s_pin_config_t pin_rx { .bck_io_num 26, .ws_io_num 25, .data_out_num -1, .data_in_num 22 }; i2s_driver_install(I2S_NUM_0, i2s_rx_config, 0, NULL); i2s_set_pin(I2S_NUM_0, pin_rx); }// I2S1 播放到 MAX98357 功放 void i2s_speaker_init() { i2s_config_t i2s_tx_config { .mode (i2s_mode_t)(I2S_MODE_MASTER | I2S_MODE_TX), .sample_rate 16000, .bits_per_sample I2S_BITS_PER_SAMPLE_32BIT, // 写入 32 位帧有效数据放高 16 位 .channel_format I2S_CHANNEL_FMT_ONLY_LEFT, .communication_format I2S_COMM_FORMAT_STAND_I2S, .intr_alloc_flags ESP_INTR_FLAG_LEVEL1, .dma_buf_count 8, .dma_buf_len 256, .use_apll false, .tx_desc_auto_clear true, // TX 下应开启避免 DMA 残留数据刷杂音 .fixed_mclk 0 }; i2s_pin_config_t pin_tx { .bck_io_num 32, .ws_io_num 33, .data_out_num 27, .data_in_num -1 }; i2s_driver_install(I2S_NUM_1, i2s_tx_config, 0, NULL); i2s_set_pin(I2S_NUM_1, pin_tx); }上面的配置里两个关键参数需要重点说明。bits_per_sample I2S_BITS_PER_SAMPLE_32BIT表示的是 I2S 总线上传输的帧位宽而不是有效音频位深。ICS-43434 的数据左对齐到 32 位读取后手动右移 8 位得到 16 位有效数据写入 MAX98357 时再把 16 位数据左移 8 位放回 32 位帧中。tx_desc_auto_clear这个参数在 TX 模式下建议置为true否则 DMA 描述符里残留的旧数据会在无新数据可写时被重复播放产生刺耳杂音。初始化完成后可以先用一个最简单的本地回环做验证从 I2S0 读出数据处理成 16 位再写入 I2S1。如果扬声器能听到自己说话的回声不接网络说明整条音频通路已经打通。void loop() { int32_t sample[512]; size_t bytes_read 0; size_t bytes_written 0; int16_t out[512]; esp_err_t err i2s_read(I2S_NUM_0, sample, sizeof(sample), bytes_read, portMAX_DELAY); if (err ESP_OK bytes_read 0) { int cnt bytes_read / 4; // 32 位样本个数 for (int i 0; i cnt; i) { out[i] (int16_t)(sample[i] 14); // 右移 8 位取高 16 位再放大 2 倍补偿音量 } i2s_write(I2S_NUM_1, out, cnt * 2, bytes_written, portMAX_DELAY); } }这里采样值右移 14 位而不是 8 位是一个实际调试中的经验值ICS-43434 在正常说话音量下的输出幅值远小于满量程单纯右移 8 位获得的数据会明显偏小听感音量过低。右移 14 位相当于在取出高 16 位的基础上额外乘了 2 倍属于一个粗糙的固定增益补偿。真实产品里应该用 AGC 或者软音量控制但在原型验证阶段这个补偿很有用。3. 无线传输链路用 UDP 承载 20ms 一包的语音流3.1 为什么对讲机场景必须选 UDP 而不是 TCP对讲机音频对实时性的要求远高于可靠性。TCP 为了保证数据完整会在丢包后重传已经错过时间窗口的数据包这些包到达播放端时已经“过期”播放出来就是一顿一顿的噪音同时 TCP 的拥塞控制会把延迟抖动进一步放大。UDP 没有重传丢包最多造成一个短促的间隙听感上往往只像一个字被切掉一点远比重传引发的卡顿易接受。在局域网环境下UDP 丢包率本身很低所以更不用担心可靠性问题。常见做法是两个 ESP32 直连同一个路由器或者其中一个 ESP32 开 SoftAP、另一个以 STA 模式连接。UDP 单播即可满足点对点通话如果后续要做一呼多响的群组对讲改成广播地址并让接收端过滤特定端口的数据就能实现代码改动很小。这里的“无线链路”方案不依赖任何外网服务所有数据都在本地局域网内转发。3.2 包长、发送节奏与抖动缓冲区的下限选定 16kHz、16 位单声道后码率是固定的每秒 32000 字节。音频要打包成 UDP 数据报发送包长直接决定发送频率和延迟上限。我一般选择 20ms 为一个音频帧即每包 640 字节。20ms 是语音通信行业里普遍认可的一个平衡点包太短如 5ms会导致每秒发包 200 个Wi-Fi 的节能模式和路由器的转发能力都吃紧包太长如 100ms虽然网络效率高但明显感觉说话有拖沓感。这里有一组计算可以直观感受带宽占用。每包音频负载 640 字节加上 UDP 头 8 字节、IP 头 20 字节链路层实际约 670 字节左右每秒 50 包合计不足 300kbps。对于 Wi-Fi 的链路速度而言非常充裕。接收端要注意抖动缓冲区的设计。UDP 包从发送端到接收端并不是严格等间隔到达的Wi-Fi 的 beacon 间隔、路由器调度都会造成抖动。接收端用 ESP32 的 I2S DMA 缓冲本身就能吸收一部分抖动所以不一定要额外实现 FIFO 队列当 I2S 写数据的速度略快于 UDP 包到达速度时DMA 缓冲会自然填补间隙直至 underrun。如果测试中发现频繁出现断音优先增大dma_buf_count而不是急于实现应用层队列。3.3 发送端与接收端的 UDP 音频代码实现这里用 Arduino 的WiFiUdp库实现发送和接收。发送端放在 loop 里读取 20ms 音频后直接beginPacket发出。#include WiFi.h #include WiFiUdp.h WiFiUDP udp; IPAddress peerIP(192, 168, 1, 200); // 对端 ESP32 的 IP const uint16_t PORT 50001; // 读取 20ms 音频并发送 void send_audio_packet() { int16_t pcm[320]; // 20ms * 16kHz 320 个样本 size_t bytes_read 0; esp_err_t err i2s_read(I2S_NUM_0, pcm, sizeof(pcm), bytes_read, pdMS_TO_TICKS(50)); if (err ! ESP_OK || bytes_read 0) { return; } int bytes_to_send (bytes_read / 4) * 2; // 32 位转 16 位后的字节数 // 发送前手动把每个 32 位样本的高 16 位提取出来 // 这里为简化演示已假设 pcm 缓冲区预先做过缩放转换 udp.beginPacket(peerIP, PORT); udp.write((const uint8_t *)pcm, bytes_to_send); udp.endPacket(); } void loop() { send_audio_packet(); delay(5); // 适当等待避免阻塞 I2S 读操作 }这段代码有一个隐含的关键点i2s_read请求读sizeof(pcm)也就是 640 字节在 16kHz、32 位帧格式下正好对应 20ms 音频。pdMS_TO_TICKS(50)作为超时避免 I2S 数据不足时无限阻塞整个网络处理。如果改用portMAX_DELAY在 DMA 缓冲为空时 loop 会停滞可能导致 UDP 接收端无法及时处理入站数据包。接收端代码更短核心是parsePacket读取网络数据后直接i2s_writevoid recv_audio_packet() { int packet_size udp.parsePacket(); if (packet_size 0) { return; } uint8_t buf[700]; int len udp.read(buf, sizeof(buf)); if (len 0) { return; } // 将 16 位 PCM 数据左移回 32 位帧高位 int16_t *pcm (int16_t *)buf; int sample_cnt len / 2; int32_t frame[700]; for (int i 0; i sample_cnt; i) { frame[i] ((int32_t)pcm[i]) 14; // 与发送端右移量保持一致 } size_t bytes_written 0; i2s_write(I2S_NUM_1, frame, sample_cnt * 4, bytes_written, pdMS_TO_TICKS(50)); }接收端注意buf大小要留足余量700 字节对 640 字节的音频包加 UDP/IP 头绰绰有余。i2s_write前的移位操作是为了把 16 位数据还原成 32 位帧结构。如果你在初始化时配置了I2S_BITS_PER_SAMPLE_16BIT就不需要这个移位步骤但前面说过 16 位帧格式下 ICS-43434 的 24 位数据会被截断音质损失明显所以两端的帧位宽必须和收发数据的格式完全一致。4. 双侧对称工作把采集、发送、接收、播放排成任务4.1 半双工 PTT 还是全双工模式无线对讲机最常见的交互是半双工按住按钮说话松开按钮收听。半双工的好处不只是符合使用习惯更重要的是从根源上避免了回声问题——本地扬声器播放的声音不会在麦克风采集时被误发出去。代码上PTT 按键只需要作为发送流程的使能条件松开时不读取 I2S 麦克风数据即可。全双工模式不需要按键两边的 ESP32 同时执行采集发送和接收播放。这在技术上是可行的因为 I2S0 与 I2S1 是相互独立的 DMA 通道Wi-Fi 协议栈也支持并发收发。但全双工打开后本地扬声器的声音会直接灌进本地麦克风形成强回声。如果要做全双工必须叠加回声抑制算法否则体验远不如半双工。建议第一版直接做半双工。原型验证全双工链路是否通可以用 5.2 提到的 ducking 方案临时压制回声而不是一开始就上自适应滤波器。4.2 FreeRTOS 任务切分与优先级设置即使 loop 里同时写发送和接收逻辑也能工作但音频处理和网络收包一旦互相阻塞延迟就会抖动。更稳定的做法是把两件事拆成独立任务并指定运行核心。ESP32 是双核 MCUI2S 读取和 UDP 收发都涉及外设中断与 DMA把它们放到不同核心上可以减少调度冲突。下面是一个典型的任务分配方式// 发送任务采集 - UDP 发送 void task_send(void *param) { while (1) { if (ptt_pressed()) // 读取 GPIO5 { send_audio_packet(); } delay(2); } } // 接收任务UDP 接收 - I2S 播放 void task_recv(void *param) { while (1) { recv_audio_packet(); delay(1); } } void setup_wireless_tasks() { xTaskCreatePinnedToCore(task_send, send_task, 8192, NULL, 2, NULL, 1); xTaskCreatePinnedToCore(task_recv, recv_task, 8192, NULL, 2, NULL, 0); }优先级选 2 是经验值高于loopTaskArduino 的默认任务优先级通常是 1低于 Wi-Fi 协议栈内部任务通常在 3 到 5 之间。这样既保证音频任务能抢占低优先级的串口打印等逻辑又不会干扰 Wi-Fi 驱动的底层收发。任务栈大小 8192 字节也值得注意WiFiUdp库内部缓冲区较大栈给得太小会直接复位重启。4.3 链路验证方法从正弦波到语音接入真实人声之前先用正弦波验证整条数据通路。发送端循环生成一个 1kHz 正弦波并把数据送进 UDP 发送函数接收端把收到的数据同时写成串口波形。没有逻辑分析仪时可以在接收端串口里每隔一定字节打印当前样本值看到规律性变化的数值就说明链路是通的。还有一种强有力的验证方式是本地环回测试在发送端代码里同时初始化 I2S0 和 I2S1然后通过 UDP 把采集到的音频先发送到对端对端再原样转发回来播放。这个方案同时验证了两个板的采集、无线收发、播放全链路比各自单独测试更接近真实工作状态。5. 延迟预算、回音抑制与一个可复用的测延迟技巧5.1 40ms 延迟预算怎么分配对讲机可接受的端到端延迟一般是 100ms 以内但我建议按 40ms 作为设计目标。其中采集端 I2S DMA 缓冲约 8msUDP 发送等待和调度约 5msWi-Fi 空中传输约 1 到 3ms接收端 DMA 缓冲约 8ms剩下的约 16ms 留给任务调度抖动。这个预算下即使路由器在 beacon 间隙出现 10ms 级别的抖动整体仍在 60ms 以内通话感很自然。压缩这个延迟的关键在于减少 DMA 缓冲区大小但减少缓冲区意味着 underrun 风险增加。一个实测有效的做法是把dma_buf_count从 8 降到 4同时把dma_buf_len降到 128然后连续通话几分钟观察是否有爆音。如果没有就再进一步如果出现爆音说明接收端播放速度高于网络供给速度需要回退一档。5.2 全双工下最简单的回声抑制ducking全双工模式下一个直观但非常有效的回声压制方法是音量衰减当本端检测到麦克风有语音输入时立刻把扬声器播放音量压低。这个技术叫 ducking通话系统中常用于压低背景音乐在对讲机全双工场景下同样适用。float speaker_gain 1.0f; // 在接收任务里写入 I2S 前应用增益 void apply_speaker_gain(int32_t *frame, int cnt, float gain) { for (int i 0; i cnt; i) { frame[i] (int32_t)(frame[i] * gain); } }检测麦克风语音能量的代码很简单每 10ms 统计一次当前缓冲区的峰值绝对值超过某个阈值就判定为“本端在说话”此时将speaker_gain快速拉低到 0.15当能量低于阈值持续 100ms 后再恢复为 1.0。这个策略能显著减轻“自己听到自己回声”的感觉并不能完全消除但成本几乎为零不占用额外 CPU。5.3 环回测延迟法不算绝对时间也能得到单向延迟双向对讲时很难精确测量单向延迟因为你无法同时让两端以同一时钟计时。这里有一个很实用的环回技巧发送端 A 发一个带时间戳标记的 UDP 包给接收端 BB 收到后不做任何处理立即把同一包原样发回 A。A 测量从发出到收到回包的时间差除以 2就得到端到端的单向延迟。// A 端发送测试包并计算往返时间 unsigned long t_start millis(); udp.beginPacket(peerIP, PORT); udp.write((const uint8_t *)PING, 4); udp.endPacket(); while (millis() - t_start 1000) { if (udp.parsePacket() 0) { unsigned long rtt millis() - t_start; Serial.printf(单程延迟约 %lu ms\n, rtt / 2); break; } } // B 端收到任何数据包都原样回发 int len udp.parsePacket(); if (len 0) { udp.read(buf, sizeof(buf)); udp.beginPacket(udp.remoteIP(), udp.remotePort()); udp.write(buf, len); udp.endPacket(); }这个测试包含的是 Wi-Fi 空中的双向传输时间物理链路上是同一跳所以除以 2 得到的是“点到点单向延迟”I2S 采集和播放的缓冲延迟不包含在内。实际对讲时的感知延迟还要再加上两端 DMA 缓冲的时间所以测量值通常比人耳感知值低一些。调试时只要这个测量值稳定在 15ms 以内说明网络侧没有瓶颈后续优化的重点应该放在 I2S DMA 配置上。本文还有配套的精品资源点击获取