简介STM32双工网络语音源代码面向嵌入式开发学习者与网络通信方向工程师基于STM32微控制器与LwIP轻量级TCP/IP协议栈构建可双向实时传输语音的通信系统解决资源受限设备上网络语音通话的落地问题。资源包共1255个文件约17.48MB以c与h源码、cfg配置、o与d编译中间文件、crf与uvproj工程文件为主另含sct分散加载、hex与axf可执行文件及readme说明完整保留Keil工程结构与调试痕迹。项目覆盖音频采集编码、TCP可靠传输、双工收发调度与网络编程等关键环节代码中可见4k缓冲区收发实验与多版本调试备份便于读者对照理解语音数据从采集、封装到解码播放的完整链路。目前已有866人学习下载适合希望深入掌握嵌入式网络语音通信与LwIP移植的开发者参考实践。1. 从一块 F407 板子跑通全双工语音对讲说起前阵子帮一个做楼宇对讲的朋友看方案他手里有一份 STM32 双工网络语音源代码硬件是常见的 STM32F407 LAN8720 方案需求很朴素两块板子插上网线能像对讲机一样双向说话不卡、不断、不炸音。听起来简单但真跑起来坑比想象中多——采样率对不上、LwIP 缓冲一满就丢包、TCP 粘包把音频帧切得七零八落。这份代码的价值就在于它把「ADC 采样 → 编码 → TCP 打包 → 网络发送 → 接收 → 解码 → DAC 播放」这条链路完整串起来了而且收发是并行的不是那种只能单向喊话的半成品。适合谁适合已经能点灯、能跑通 LwIP ping 的嵌入式工程师想找一个能直接改、能听效果的语音通信参考实现。如果你连 CubeMX 都没配过建议先把以太网外设跑通再来看这份代码不然调试起来会很痛苦。2. 双工语音链路的骨架从 I2S 采样到 TCP 收发的数据流2.1 为什么选 TCP 而不是 UDP很多人第一反应是语音用 UDP 更实时但这份代码选了 TCP原因很实际在局域网对讲场景里丢一帧音频就是「咔」一声UDP 不保证顺序和到达得自己写重传和抖动缓冲工作量翻倍。TCP 虽然握手慢、有拥塞控制但在百兆局域网里带宽绰绰有余8kHz 采样、16bit 单声道一路也就 128kbpsTCP 完全扛得住。代价是延迟会比 UDP 高几十毫秒对讲场景能接受。代码里 TCP 服务端和客户端是并存的一块板子既监听端口又主动连接对方形成两条独立连接一条发一条收互不干扰。这就是「双工」的实现方式——不是一条连接上同时读写而是两条单向流拼出来的全双工。2.2 音频采集与播放的时钟配置采样率设的是 8kHz这是语音通信的经典值再高对讲没必要再低音质明显发闷。I2S 时钟树要算准F407 的 I2S PLL 配置不对出来的采样率会偏对方听到的声音会变调。常见做法是用 CubeMX 配 I2S PLL让 I2SxCLK 落在 8kHz × 256 2.048MHz 附近。// I2S 时钟配置片段基于 HAL 库 // 目标8kHz 采样率16bit 数据主时钟输出使能 hi2s2.Instance SPI2; hi2s2.Init.Mode I2S_MODE_MASTER_TX; hi2s2.Init.Standard I2S_STANDARD_PHILIPS; hi2s2.Init.DataFormat I2S_DATAFORMAT_16B; hi2s2.Init.MCLKOutput I2S_MCLKOUTPUT_ENABLE; hi2s2.Init.AudioFreq I2S_AUDIOFREQ_8K; // 关键8kHz hi2s2.Init.CPOL I2S_CPOL_LOW; hi2s2.Init.ClockSource I2S_CLOCK_PLL; hi2s2.Init.FullDuplexMode I2S_FULLDUPLEXMODE_ENABLE;这里AudioFreq填 8KHAL 库会自动反算分频系数但前提是 I2S PLL 的输入频率在允许范围内。如果发现声音变调先拿示波器量 I2S 的 WS 引脚正常应该是 8kHz 方波偏了就回头查 PLL 配置。2.3 音频缓冲区的双缓冲设计采集和发送速度不匹配是丢帧的根源。代码里用了双缓冲一个缓冲区在填 ADC 数据时另一个正在被 TCP 发送填满后交换。这样采集不会因为网络发送阻塞而停摆。#define AUDIO_BUF_SIZE 160 // 20ms 8kHz int16_t audio_buf[2][AUDIO_BUF_SIZE]; volatile uint8_t buf_idx 0; volatile uint8_t buf_ready[2] {0, 0}; // DMA 半满/全满中断里切换缓冲区 void HAL_I2S_RxHalfCpltCallback(I2S_HandleTypeDef *hi2s) { buf_ready[0] 1; // 前半满标记可发送 } void HAL_I2S_RxCpltCallback(I2S_HandleTypeDef *hi2s) { buf_ready[1] 1; // 后半满 }AUDIO_BUF_SIZE取 160对应 20ms 的音频这是实时语音的常用帧长——太短网络包太碎太长延迟明显。发送线程轮询buf_ready哪个缓冲区就绪就发哪个发完清标志。注意这里用了volatile因为标志在中断和主循环之间共享不加编译器可能优化掉。3. LwIP 协议栈的移植与 TCP 收发线程的落地3.1 LwIP 在裸机与 RTOS 下的两种跑法这份代码默认是裸机 轮询的模式MX_LWIP_Process()放在主循环里反复调用。好处是不依赖 RTOS移植简单坏处是网络处理会占用主循环时间音频采集如果也用轮询就会互相拖累。所以实际项目里我一般会把它挪到 FreeRTOS 下给 LwIP 单独一个任务音频采集和发送各一个任务用队列传数据。裸机模式下MX_LWIP_Process的调用频率直接影响吞吐。如果发现 TCP 发送卡顿先看主循环里有没有延时函数把节奏拖慢了。3.2 TCP 服务端与客户端的建立代码里服务端监听 8080 端口客户端主动连对方的 8080。两块板子烧同样的程序靠拨码开关或者按键决定谁先发起连接避免同时连导致冲突。// TCP 服务端初始化 struct tcp_pcb *server_pcb tcp_new(); tcp_bind(server_pcb, IP_ADDR_ANY, 8080); server_pcb tcp_listen(server_pcb); tcp_accept(server_pcb, audio_accept_cb); // 客户端连接 struct tcp_pcb *client_pcb tcp_new(); ip_addr_t dest_ip; IP4_ADDR(dest_ip, 192, 168, 1, 100); // 对方 IP tcp_connect(client_pcb, dest_ip, 8080, audio_connected_cb);tcp_accept的回调里要保存新的 pcb 指针后续发送都往这个 pcb 上写。注意tcp_write之后必须调tcp_output否则数据可能躺在缓冲里不发。这是新手最容易漏的一步现象就是「连上了但对方收不到任何声音」。3.3 音频数据的打包与粘包处理TCP 是字节流没有消息边界。如果直接把音频帧往tcp_write里塞接收端tcp_recv回调拿到的数据长度是随机的可能半帧也可能两帧粘一起。解决办法是加一个简单的帧头每帧前面加 2 字节长度字段。// 发送端打包 uint8_t pkt[AUDIO_BUF_SIZE * 2 2]; pkt[0] (AUDIO_BUF_SIZE * 2) 8; pkt[1] (AUDIO_BUF_SIZE * 2) 0xFF; memcpy(pkt[2], audio_buf[buf_idx], AUDIO_BUF_SIZE * 2); tcp_write(pcb, pkt, sizeof(pkt), TCP_WRITE_FLAG_COPY); tcp_output(pcb); // 接收端解包简化逻辑 static uint8_t rx_buf[1024]; static uint16_t rx_len 0; err_t audio_recv_cb(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) { if (p NULL) { tcp_close(pcb); return ERR_OK; } pbuf_copy_partial(p, rx_buf[rx_len], p-tot_len, 0); rx_len p-tot_len; // 按帧头长度切分凑够一帧就送 DAC while (rx_len 2) { uint16_t frame_len (rx_buf[0] 8) | rx_buf[1]; if (rx_len frame_len 2) break; // 不够一帧等下次 play_audio(rx_buf[2], frame_len); memmove(rx_buf, rx_buf[frame_len 2], rx_len - frame_len - 2); rx_len - (frame_len 2); } tcp_recved(pcb, p-tot_len); pbuf_free(p); return ERR_OK; }帧头用 2 字节大端表示长度接收端维护一个累积缓冲区凑够一帧才播放剩余数据memmove前移。tcp_recved必须调告诉协议栈这包处理完了否则接收窗口会越来越小直到卡死。这套逻辑不复杂但少了任何一步都会出问题。4. 避坑与排查双工语音调试中最容易翻车的五个点4.1 现象能 ping 通但 TCP 连不上原因通常是tcp_bind的端口被占用或者tcp_listen之后没有正确保存返回的新 pcb。tcp_listen会释放旧 pcb 返回新 pcb如果还用旧指针accept 永远不会触发。解决server_pcb tcp_listen(server_pcb);必须重新赋值。4.2 现象单向能通反向没声音双工靠两条连接检查客户端是否真的发起了tcp_connect以及连接回调里有没有把 pcb 存到全局变量。常见错误是回调里用了局部变量存 pcb函数返回后指针失效。解决用static或全局指针保存。4.3 现象声音断断续续像卡带多半是发送速度跟不上采集速度或者tcp_write返回ERR_MEM被忽略了。ERR_MEM表示协议栈缓冲满此时应该等一会儿重发而不是丢弃。解决检查tcp_write返回值ERR_MEM时把数据暂存等tcp_sndbuf有空间再发。4.4 现象对方听到的声音变调采样率不匹配。自己这边 8kHz对方如果配成 16kHz声音会快一倍。解决两端AudioFreq必须一致且 I2S PLL 配置要保证实际时钟准确。用示波器量 WS 引脚是最直接的验证手段。4.5 现象跑几分钟后死机内存泄漏。pbuf_free没调或者tcp_recv回调里p NULL时没关连接。LwIP 的 pbuf 池是有限的漏几次就耗尽。解决每个tcp_recv分支都要保证 pbuf 被释放连接断开时清理 pcb。5. 进阶技巧用环形缓冲和动态帧长把延迟压到 50ms 以内前面那套双缓冲 固定 160 样本的方案延迟大概在 80~120ms对讲够用但如果想做更接近实时的通话得再抠一抠。我后来改成了环形缓冲 动态帧长延迟能压到 50ms 左右。核心思路是采集端不再等缓冲区满才发而是每采集到一小段比如 40 样本5ms就检查一次网络发送队列如果tcp_sndbuf足够就直接发。接收端用环形缓冲平滑抖动播放线程按固定节奏从环形缓冲取数据取不到就补静音避免断音。// 环形缓冲定义 #define RING_SIZE 2048 static int16_t ring[RING_SIZE]; static volatile uint16_t ring_wr 0, ring_rd 0; // 写入接收回调里调 void ring_write(int16_t *data, uint16_t len) { for (uint16_t i 0; i len; i) { ring[ring_wr] data[i]; ring_wr (ring_wr 1) % RING_SIZE; } } // 读取DAC 播放中断里调 void ring_read(int16_t *out, uint16_t len) { for (uint16_t i 0; i len; i) { if (ring_rd ! ring_wr) { out[i] ring[ring_rd]; ring_rd (ring_rd 1) % RING_SIZE; } else { out[i] 0; // 欠载补静音 } } }环形缓冲的大小要权衡太小会频繁欠载太大会增加延迟。2048 个样本在 8kHz 下是 256ms 的容量实际用的时候只让它存 50ms 左右的数据多了就丢最旧的。动态帧长则是根据tcp_sndbuf的剩余空间决定这次发多少空间多就多发空间少就少发避免ERR_MEM。验证延迟有个土办法两块板子放一起对着一块说话听另一块的声音用手机录音看波形上原声和回声的时间差。50ms 以内基本感觉不到明显延迟100ms 以上会有「对讲机感」。从那以后我每次调语音链路都强制先量 WS 引脚频率、再抓一次 TCP 收发日志、最后才听声音这三步走完基本不会翻车。希望帮到你。本文还有配套的精品资源点击获取