企业官网建设流程全解析

我最初做这个项目，纯粹是因为受不了市面上那些所谓的“儿童对讲机”——延迟高得离谱，音质像从水底传上来的，而且根本没法和自己手头的智能家居联动。后来发现ESP32-S3这颗芯片天生就是干这个的料：双核240MHz、内置Wi-Fi和BLE、还带I2S数字音频接口，几乎是把“做一台网络对讲机”的零件全给你凑齐了。这篇文章不聊虚的，直接把我的实现方案、踩过的坑、以及最终跑通的代码逻辑全部分享出来，给同样想折腾无线语音传输的朋友一条近路。

先说说这个项目做完能干什么：两台（或更多）ESP32-S3设备在同一个Wi-Fi网络下，可以实现半双工语音对讲，按一下按键说话，松开按键听对方回复，实测延迟在200毫秒左右，音质清晰可懂。整个过程不依赖任何云服务，数据只在局域网内跑，也就意味着没有隐私泄露和额外费用。适合的场景很广：家里老人看护、店内店员沟通、临时工作小组联络，甚至是做机器人遥控时的语音回传。如果你刚好手头有ESP32-S3开发板，那这个项目的硬件成本可以压到非常低。

需要说明的是，这套实现默认你具备基础的ESP-IDF开发环境配置能力，命令行会一点，C语言能看懂。如果你只会Arduino，后面我也会给一些思路提示，但主流代码还是基于ESP-IDF来写的——原因很简单，ESP-IDF对I2S的DMA缓冲控制更精细，这是低延迟音频传输的关键。

1. 项目整体设计与方案选型

1.1 核心需求拆解：这不是一个“装上就能用”的小玩意

对讲机本质上是三件事：把声音变成数字信号、把数字信号从一个设备挪到另一个设备、再变回声音放出来。听起来很简单，但每一步都有坑。我在动手之前把需求拆成了四个模块：

• 音频采集：用I2S接口接数字麦克风（或模拟麦克风+ADC），把模拟声音转成PCM数据流
• 音频编码：PCM裸数据太大，一个8000Hz采样率、16bit位深的单声道流每秒就是128Kbit，Wi-Fi传这玩意儿浪费带宽，必须压一压
• 无线传输：ESP32-S3自带Wi-Fi，用UDP协议在局域网内组播或单播，实现数据从麦克风端到扬声器端的搬运
• 音频播放：接收端把数据解压、经I2S输出到功放和扬声器

这四个模块天然就是一条流水线，所以整体架构根本不复杂，难点全在“实时性”上——你要在有限的CPU时间片和Wi-Fi带宽内，让整条链路跑得足够快、足够稳。

1.2 方案选型考量：为什么是UDP裸传 + ADPCM压缩

方案选型这里我挣扎过几轮。音频编码方面，最初考虑过直接传PCM，毕竟ESP32-S3的Wi-Fi带宽理论上足够跑128Kbit的流。但实际一测就发现不行：802.11n在2.4GHz下的实际吞吐量受环境影响很大，稍微隔一堵墙，TCP重传机制就会让延迟飙到一秒以上。而PCM这种无压缩流一旦丢包，就是一段“嘶啦嘶啦”的破音，体验极差。

后来转向ADPCM编码，这是老掉牙的技术了——上世纪80年代用在电话系统里的，4:1压缩率，算法简单到可以手写。选它有几个硬核理由：

• CPU开销极低：整个编码器/解码器加在一起不到100行C代码，单次编码一个样本只需要几次加法移位操作，ESP32-S3主频240MHz跑这种运算几乎是零成本
• 压缩率够用：把16bit的PCM压成4bit，8000Hz采样率下单路只需要32Kbit带宽，Wi-Fi传这玩意儿绰绰有余
• 抗丢包能力强：ADPCM每个样本只依赖前一个样本，没有帧间压缩依赖。就算连续丢了几个包，最多就是那几十毫秒的短暂杂音，下一包数据到达立即恢复，不会出现声音长时间卡死的情况

传输协议方面，我几乎没有犹豫就选了UDP。TCP当然更可靠，但它的重传机制对实时语音来说是个灾难——你不需要“晚到但完整”的数据，你需要的是“及时但可能缺一点”的数据。语音通信里，丢掉100毫秒的声音远好过延迟500毫秒让别人等你说完一句话。

1.3 硬件选型：手头有什么就先用什么

硬件方面我用的是一块很常见的ESP32-S3-DevKitC-1开发板，配INMP441数字麦克风（I2S接口，不用做模拟信号调理）和MAX98357A数字功放（同样是I2S接口，直接驱动3W小喇叭）。这套组合的好处是足够简单——没有模拟电路要调，所有音频信号通路都是数字的，焊几根杜邦线就能跑。

如果你手头只有模拟麦克风和功放，也不是不行。ESP32-S3内置ADC可以采模拟信号，但采样精度只有12bit，噪声表现也远不如数字方案。我的建议是，第一次做这个项目不要在这种地方省事，数字麦克风+数字功放能帮你排掉一大堆硬件上的干扰问题，把精力集中在软件逻辑上。

2. 关键参数怎么定：采样率、缓冲区与延迟的取舍

2.1 为什么采样率只用8000Hz就够，甚至更好

对讲机和音乐播放器是完全不同的场景。音乐要的是频响宽广、细节丰富，而对讲机只需要保住语音的清晰度就够了。人说话的基频大概在85Hz到300Hz之间，辅音信息集中在300Hz到3400Hz，这就是传统电话线路只传300到3400Hz频带的原因——人类语音的可懂度在这个窄带范围内已经足够了。

所以我最终把采样率定在8000Hz，16bit位深，单声道。一分钱一分货，这个配置下的音频带宽完全匹配语音通信需求，而且带来三方面的好处：

• 数据量小：8K采样 × 2字节 × 1声道 = 16K字节/秒，即便ADPCM压缩后只有4K字节/秒，整个传输链路非常宽裕
• 延迟低：我用了20毫秒的帧长，也就是每帧160个采样。20毫秒积攒一包数据，网络层传输加上排队，端到端延迟很容易控制在200毫秒以内
• 内存占用小：ESP32-S3的PSRAM虽然不小，但音频这种持续流数据能省则省，小数据流对SRAM的压力几乎可以忽略

2.2 DMA缓冲策略：I2S为什么一定要用DMA模式

I2S接口本身是个非常简单的外设——它按位时钟把数据从数据线上移位进/出。但如果你让CPU直接参与每一位数据的搬运，那基本上什么事情都别干了。所以ESP32-S3的I2S外设支持DMA模式，数据在内存和外设之间自动搬运，搬运完成触发中断，CPU只需要处理成块的数据即可。

具体到调试中，我把DMA缓冲设为4个描述符，每个描述符管理1200个采样（2400字节）。这样每积累大约150毫秒的数据才会触发一次传输完成中断。这个缓冲大小是个折中方案：

• 缓冲太小：中断触发频率太高，CPU忙于处理中断，影响其他任务调度
• 缓冲太大：数据在DMA缓冲里滞留的时间变长，直接增加端到端延迟

你可能注意到了——150毫秒的DMA缓冲时间已经相当于整条链路预期延迟的一大半了。后来我实际调参时把DMA描述符的管理方式改成了双缓冲（两个1200采样缓冲区交替使用），让音频流的处理更像流水线，而不是攒一批传一批。

关于DMA还有一个经验要分享：如果你打开ESP32-S3的I2S文档，会看到DMA描述符数量和每个描述符承载大小的关系。这两个参数的乘积决定了中断频率和缓冲延迟，实际调的时候要用示波器或者逻辑分析仪去量WS（字选择）信号，看真实采样率是否稳定。如果发现WS信号出现不规则的抖动，多半是DMA优先级被其他外设抢占了。

2.3 网络缓冲、Wi-Fi排队延迟和最终延迟预算

项目做完后我测过几次完整链路的延迟数据，用的是“本地播放一个1000Hz方波，用麦克风采集，在接收端测输出”的方法，大致分布是这样的：

实测听到的效果是，按键按下到对方听到声音，主观感受大约就是“对方延迟了小半拍”。对于对讲机这种半双工应用场景，这个延迟完全可以接受。而且，整个链路中最大头的延迟其实来自I2S的DMA缓冲，而非网络传输。所以如果你想进一步压低延迟，优先动的参数是DMA缓冲大小和帧长，而不是去折腾路由器。

Wi-Fi侧还有一个很影响延迟的东西是Wi-Fi的省电模式。ESP32-S3默认开启了Wi-Fi Modem Sleep，这会让网卡在空闲时进入低功耗状态，导致有包到达时先要花额外时间从休眠中唤醒。我在测试中把这个功能关掉了（设置esp_wifi_set_ps(WIFI_PS_NONE)），发送延迟从平均30ms降到5ms以内。代价是功耗从微安级上升到了毫安级，但对一个带功放的对讲机来说，这点功耗本来就在预期之内。

3. 实操过程与核心环节实现

3.1 搭建最小硬件系统

硬件连接非常简单，按表接好就行：

一个很容易忽略的细节：INMP441的L/R引脚如果悬空，它默认走左声道数据。而MAX98357A的LRC引脚由ESP32-S3控制，是全双工I2S里的字选择。两者虽然在物理上是两条独立的I2S总线，但时钟配置必须一致，否则你录音是正常的，放音却可能出现明显的“金属声”或“沙沙声”。我在这上面至少浪费了半天——麦克风用左声道，功放也应该配置成左声道，两个I2S外设的WS极性必须相同。

3.2 ESP-IDF工程结构和核心代码：发送端实现

工程用ESP-IDF v5.x创建，组件结构是标准的三块：Wi-Fi连接、I2S驱动、ADPCM编码。发送端代码我是放在一个独立任务里的，任务一旦创建就一直运行，用队列和按键任务通信。

先看I2S初始化代码，这是整个项目的地基：

#include "driver/i2s_std.h" void i2s_mic_init(void) { i2s_chan_config_t chan_cfg = I2S_CHANNEL_DEFAULT_CONFIG(I2S_NUM_AUTO, I2S_ROLE_MASTER); i2s_new_channel(&chan_cfg, &tx_chan, NULL); // 麦克风只用于接收，所以rx为NULL即可 i2s_std_config_t std_cfg = { .clk_cfg = I2S_STD_CLK_DEFAULT_CONFIG(8000), .slot_cfg = I2S_STD_PHILIPS_SLOT_DEFAULT_CONFIG(I2S_DATA_BIT_WIDTH_16BIT, I2S_SLOT_MODE_MONO), .gpio_cfg = { .mclk = I2S_GPIO_UNUSED, .bclk = GPIO_NUM_6, .ws = GPIO_NUM_5, .dout = I2S_GPIO_UNUSED, .din = GPIO_NUM_4, .invert_flags = { .mclk_inv = false, .bclk_inv = false, .ws_inv = false, }, }, }; i2s_channel_init_std_mode(rx_chan, &std_cfg); i2s_channel_enable(rx_chan); }

这里有两处比较关键：I2S_SLOT_MODE_MONO告诉驱动只接收单声道数据，符合INMP441的输出格式。另一个是ws_inv = false，它匹配INMP441的数据手册时序。如果你把麦克风换成别的型号，这个极性标志可能要翻转，接收到的数据会从“能听清但沙沙响”变成完全正常的差异。

主循环里，读取麦克风并编码的代码长这样：

#define FRAME_SAMPLES 160 // 20ms @ 8kHz void sender_task(void *arg) { int16_t pcm_buf[FRAME_SAMPLES]; uint8_t adpcm_buf[FRAME_SAMPLES / 2]; size_t bytes_read = 0; while (1) { if (button_pressed) { // 从I2S读取一帧PCM数据 i2s_channel_read(rx_chan, pcm_buf, FRAME_SAMPLES * sizeof(int16_t), &bytes_read, portMAX_DELAY); adpcm_encode(pcm_buf, adpcm_buf, FRAME_SAMPLES); // UDP发送，源端口固定，方便接收端识别 udp_send(adpcm_buf, sizeof(adpcm_buf)); } vTaskDelay(pdMS_TO_TICKS(10)); } }

3.3 ADPCM编码实现：为什么不用库，直接手写

ADPCM的核心思想是：不对每个采样点本身编码，而是对“当前采样和前一个采样的差值”进行编码。差值通常比原始值小，而且变化率更平滑，所以可以用更少的位数去量化。

这个算法精妙的地方在于自适应量化步长——差值大的时候，步长自动变大；差值小的时候，步长自动收紧。这样即便只用4bit（16个量化级别），也能跟上大幅度声音变化。

我的实现参考了IMA ADPCM标准，只写了编码器和解码器两个核心函数。编码器核心代码：

static const int16_t step_table[89] = { 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 19, 21, 23, 25, 28, 31, 34, 37, 41, 45, 50, 55, 60, 66, 73, 80, 88, 97, 107, 118, 130, 143, 157, 173, 190, 209, 230, 253, 279, 307, 337, 371, 408, 449, 494, 544, 598, 658, 724, 796, 876, 963, 1060, 1166, 1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749, 3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484, 7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289, 16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767 }; void adpcm_encode(const int16_t *pcm, uint8_t *adpcm, size_t sample_count) { int16_t predictor = 0; int8_t step_index = 0; int diff, step_size, vpdiff, output; uint8_t code; for (size_t i = 0; i < sample_count; i += 2) { // 编码第一个采样 diff = pcm[i] - predictor; step_size = step_table[step_index]; if (diff >= 0) code = 0; else { code = 8; diff = -diff; } int temp_step = step_size; if (diff >= temp_step) { code |= 4; diff -= temp_step; } temp_step >>= 1; if (diff >= temp_step) { code |= 2; diff -= temp_step; } temp_step >>= 1; if (diff >= temp_step) code |= 1; // 用编码后的code重建预测值，保证编解码一致性 vpdiff = step_size >> 3; if (code & 4) vpdiff += step_size; if (code & 2) vpdiff += step_size >> 1; if (code & 1) vpdiff += step_size >> 2; if (code & 8) predictor -= vpdiff; else predictor += vpdiff; if (predictor > 32767) predictor = 32767; else if (predictor < -32768) predictor = -32768; step_index += index_adjust[code & 7]; if (step_index < 0) step_index = 0; if (step_index > 88) step_index = 88; output = code << 4; // 高4bit存第一个采样 // 编码第二个采样，逻辑同上，结果存低4bit // ...（略，与上面相同结构） adpcm[i / 2] = (uint8_t)output; } }

编码过程需要注意的只有一点：预测器的重建值必须和解码端完全一致。也就是使用code反推出预测值，而不是拿原始PCM值作为下一帧的预测基准。否则编解码两端各自的预测器会越走越偏，每经过一帧误差累积一点，几秒之后声音就会变得含糊不清。这个“编解码预测器同步”问题，是我自己写第一版时踩过的最深的坑。

3.4 UDP传输与Wi-Fi重连机制

UDP发送部分我用的是标准的BSD socket接口，ESP-IDF对LwIP封装得很干净：

void udp_init(void) { sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP); struct sockaddr_in dest_addr = { .sin_family = AF_INET, .sin_port = htons(8888), .sin_addr.s_addr = inet_addr("192.168.1.255"), // 子网广播地址 }; // 对端地址保存下来，发送时使用 }

用UDP广播地址发送而不是单播，好处是对讲机组网变的特别简单——不需要知道对方IP，也不需要做设备发现。任何一台设备加入同一个子网，就能自动接收到语音数据。代价是带宽浪费，但32Kbit的音频流对100Mbps以太网和Wi-Fi来说微不足道。

不过广播有个问题：路由器可能会过滤广播包，或者子网很大时广播风暴影响其他设备。如果想稳妥一点，改成UDP组播（239.0.0.1）也行，代码上只是地址字符串替换的问题。我在室内测试时广播和组播行为没有区别，但在一个大的办公网络里组播更规范。

Wi-Fi连接的处理我单独做了一个任务，负责初始化Wi-Fi并等待连接成功：

static void wifi_event_handler(void *arg, esp_event_base_t base, int32_t event_id, void *event_data) { if (event_id == WIFI_EVENT_STA_START) { esp_wifi_connect(); } else if (event_id == WIFI_EVENT_STA_DISCONNECTED) { // 自动重连 esp_wifi_connect(); } else if (event_id == IP_EVENT_STA_GOT_IP) { ip_event_got_ip_t *event = (ip_event_got_ip_t *)event_data; ESP_LOGI(TAG, "got ip: " IPSTR, IP2STR(&event->ip_info.ip)); } } void wifi_init(void) { esp_netif_init(); esp_event_loop_create_default(); esp_netif_create_default_wifi_sta(); wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT(); esp_wifi_init(&cfg); esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL); esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &wifi_event_handler, NULL); wifi_config_t wifi_config = { .sta = { .ssid = "YOUR_SSID", .password = "YOUR_PASSWORD", .threshold.authmode = WIFI_AUTH_WPA2_PSK, }, }; esp_wifi_set_mode(WIFI_MODE_STA); esp_wifi_set_config(WIFI_IF_STA, &wifi_config); esp_wifi_start(); // 关闭modem sleep，降低延迟 esp_wifi_set_ps(WIFI_PS_NONE); }

有一个很多人会忽略的细节：esp_wifi_set_ps(WIFI_PS_NONE)必须在esp_wifi_start()之后调用才会生效。如果放在启动之前，要么报错，要么被忽略。我在调试Wi-Fi延迟异常时才发现这个问题，之前用了默认的省电模式，导致UDP包的到达时间有明显的500ms级别的毛刺。

3.5 接收端实现：解码、I2S播放与按键逻辑

接收端的工作流刚好是发送端的镜像：UDP收包、ADPCM解码、I2S播放。解码器代码是编码器的逆运算，核心逻辑是：

void adpcm_decode(const uint8_t *adpcm, int16_t *pcm, size_t byte_count) { int16_t predictor = 0; int8_t step_index = 0; int step_size, vpdiff; uint8_t code; for (size_t i = 0; i < byte_count; i++) { // 解高4bit code = adpcm[i] >> 4; step_size = step_table[step_index]; vpdiff = step_size >> 3; if (code & 4) vpdiff += step_size; if (code & 2) vpdiff += step_size >> 1; if (code & 1) vpdiff += step_size >> 2; if (code & 8) predictor -= vpdiff; else predictor += vpdiff; if (predictor > 32767) predictor = 32767; else if (predictor < -32768) predictor = -32768; step_index += index_adjust[code & 7]; if (step_index < 0) step_index = 0; if (step_index > 88) step_index = 88; pcm[i * 2] = predictor; // 解低4bit，逻辑同上 code = adpcm[i] & 0x0F; // ... pcm[i * 2 + 1] = predictor; } }

播放任务里我额外做了一点小处理：UDP包是有序到达的，理论上不需要做顺序重排。但Wi-Fi在弱信号下可能乱序，所以我给每个UDP包头加了一个2字节的序号字段。接收端检查序号，如果检测到跳号（数据包丢失），就静音20毫秒而不是播放残留的旧数据。这个静音策略比播放噪声体感好得多，人耳对短促静音的感知远不如对爆音敏感。

按键逻辑上做的是经典的“PTT（Push-To-Talk）半双工”控制：按下按键，进入发送状态，麦克风数据流向网络；松开按键，进入接收状态，扬声器打开监听网络。这一块看起来简单，但有个反直觉的坑，就是按键消抖和状态切换的互锁。如果你在按下按键的同时收到了网络数据，正确行为应该是丢弃这包数据，而不是一边播放一边录音——否则就会把自己说的话也通过扬声器放出来，形成刺耳的啸叫。我在代码里做了一个简单的互斥标志位，表现稳定。

4. 常见问题与排查技巧实录

4.1 麦克风只有沙沙声或音量极小

这个现象我调试时遇到过，最终发现原因在INMP441的L/R引脚。INMP441的L/R引脚决定它输出在WS信号的高电平还是低电平周期（也就是左/右声道）。如果这个引脚悬空或者接线错误，ESP32-S3的I2S在Mono模式下会默认从某一个slot读数据，两边对不上自然就只有噪声。

排查方法是：把i2s_slot_mode_t从Mono改成Stereo，用两个声道的缓冲区打印原始数据。如果你发现两个声道里都有一个声道的数据是规律的零值或噪声，那就说明物理连接或L/R设置有问题。

另外，INMP441的数据格式是24bit，但很多例程给的DMA配置只有16bit。如果你的代码里用16bit读24bit的麦克风，会得到听起来“闷闷的”声音，因为采到的只是高16位。我在初始化里显式设置I2S_DATA_BIT_WIDTH_24BIT并配合i2s_channel_read读取3字节/样本，后来再改成16bit配合硬件左对齐，效果一样，但24bit更省心。

4.2 声音断断续续，像在过隧道

这种情况通常是UDP丢包率过高，或者Wi-Fi排队延迟不稳定。排查路径从简单到复杂：

1. 先看接收端日志里的UDP序号跳变次数。如果丢包率超过2%，无线环境肯定有问题，先挪动设备位置再测
2. 如果单台对讲机在同一个房间里也丢包，把自己的发送端靠近路由器，排除射频盲区的问题
3. 检查是否有其他设备在大量占用Wi-Fi信道。2.4GHz频段的干扰源很多，微波炉、蓝牙、USB 3.0设备都可能干扰。我的测试环境里办公室的USB 3.0硬盘盒一工作，丢包率直线上升

如果真的无法改善无线环境，软件层面能做的补救是增加前向纠错——把每个ADPCM数据包重复发一次（相隔10ms），接收端根据序号去重。代价是带宽翻倍，但对于64Kbit的流量来说仍然非常小。这个方案我在一个信号不太好的房间里实测过，丢包率从3%降到了0.3%以内，声音明显流畅了。

4.3 I2S播放有规律性的爆音

这个问题我前前后后调了一个多星期，最后定位到是两条I2S总线共用了一个时钟源，而且麦克风和功放的DMA优先级冲突。ESP32-S3有两个I2S外设，它们共享同一个APB时钟分频器。

解决办法是在初始化里给播放I2S的任务稍微调高DMA优先级，并且把两个I2S外设的时钟设置成一致的分频比。如果你用ESP-IDF v5.x，可以在i2s_new_channel之后调用i2s_channel_set_clk分别设置。两边时钟偏移太大会导致音频在长时间运行后出现周期性的相位噪声，听起来就是有规律的“啵啵啵”声。

4.4 按一下按键，两个设备都进入发送状态

这个要怪我自己没设计清楚——两台对讲机同时按下按键时，广播包是双向的，两台设备都会收到对方的声音并尝试播放，形成“你说我也说”的战团。解决方法是约定一套简单的时分复用协议：每台设备发送前先监听10ms，如果网络上有其他设备的语音包在传，就闪烁LED提示“信道繁忙”，然后自动延迟200ms重试。

这个机制简化了电路，也让用户行为更接近传统对讲机体验——大家在同一个信道上说话，自然要有先说后说的礼貌。实现上只是在发送任务里加一个“听前忙检测”的流程，读完一个UDP包如果发现是有效语音数据，就改变发送策略。

5. 实测效果与后续扩展方向

整套系统搭好后，我在家里做了几轮实测。静态场景（两台设备相距3米，同一个房间）延迟大约180ms，音质可懂度非常高，和人用微信语音发消息的感觉类似，但延迟低很多。隔一堵墙的距离（约8米）延迟会升到220ms左右，偶尔能感觉到轻微的语音“颤音”，但整体对话完全不受影响。在同一个Wi-Fi的5GHz频段下表现会更好，可惜ESP32-S3只有2.4GHz，这一点没得选。

后续想扩展的方向我列在这里，给有兴趣折腾的朋友参考：

• 多设备组网：把UDP广播改成带设备ID的组播，配合一个简单的“频道”机制，就可以实现多组对讲机在同一个网络里互不干扰
• 录音回放：在发送端加一个SD卡，把ADPCM数据流同时写盘，对讲时自动录音，结束后可在电脑上回放。这个扩展成本极低，因为ADPCM数据已经是压缩格式，一张2GB的卡能录非常久
• 语音激活（VOX）：现在是用按键PTT，改成通过检测麦克风音量自动决定是否发送，就是免按键的VOX对讲机。算法上用简单的能量阈值加退避时间就能做到，但要注意避免环境噪声误触发
• 接ESP-NOW：如果你不需要通过路由器，ESP32-S3的ESP-NOW协议可以直接点对点通信，两台设备即使不在同一个Wi-Fi网络也能对讲，只是带宽更小，ADPCM要降采样率到4K才能跑得动

我在实际使用过程中最大的体会是：这个项目的代码量不大，难点足够多但每个都能在网上找到资料，成就感非常足，而且做完之后你真的会把它当成一个日常用的小工具，而不是一个吃灰的实验板。如果你想把它作为一个入门嵌入式音频的项目，我强烈推荐从这个方案开始——短、平、快，又能学到从模拟前端到无线传输的全链路知识。