去年接到一个做同声翻译耳机的需求，要在某国产入门级蓝牙音频SoC方案上落地。这个方案芯片成本压得很低，SDK也比较成熟，很多做蓝牙耳机、带麦音箱的厂商都在用。同声翻译这个词听起来高级，落到嵌入式端其实就是一句话：把麦克风采集到的语音，经过蓝牙送到手机，手机再连云端翻译引擎，翻译结果合成语音传回耳机。整个链路不复杂，但里面每一步都有坑，尤其当你拿着一个本来就为放音乐优化的音频芯片，去硬扛实时翻译这种对延迟、音频质量和协议稳定性要求都不低的应用。
写这篇东西的初衷，是想把整个方案的选型过程、关键模块设计、联调方法和踩坑记录整理出来。内容覆盖同声翻译耳机从硬件链路到App协议的完整落地方案，适合正在做翻译耳机、翻译笔、带语音助手的音频设备相关工作的开发者，也适合刚接触蓝牙音频产品开发、想了解同声翻译到底怎么实现的新手。
先说结论：这套架构可以稳定实现“一边听对方说话、一边听翻译结果”的体验，端到端延迟控制在1秒左右，硬件BOM成本增加极少，基本上是在原蓝牙耳机方案上做软件+协议层的改造。
1. 方案设计与整体思路
1.1 同声翻译硬件做成什么样
同声翻译产品目前有三种常见形态。
第一种是纯App方案，手机麦克风直接录音，不做任何硬件定制。优点是开发量最小，只要把ASR、翻译、TTS串起来就能用。缺点是收音质量和防噪无法控制，两个人离得稍远就听不清，而且全程举着手机，体验非常奇怪。
第二种是蓝牙耳机+手机+云翻译，也就是我们这次用的架构。耳机端负责高品质拾音和播放，手机端负责语音识别、翻译和语音合成，云端提供算力。优点是芯片成本低、开发周期可控，翻译算法可以随时在App端升级，不需要改硬件。缺点是依赖手机在网，不能完全脱离App独立使用。
第三种是端侧全离线翻译，耳机内部直接跑识别和翻译模型。体验最完整，但需要带NPU的DSP或专用AI芯片，目前模组成本高、开发周期长，不适合快速出货的消费产品。
我们选第二种，核心原因是产品定义是“低成本、快速量产”。同声翻译的硬需求是语音识别、翻译质量和合成自然度，这三样恰恰是云端最强的。硬塞进一颗主打蓝牙音频的SoC里，既做不好，也没必要。
1.2 为什么选这套架构而不是端侧方案
很多人听到“同声翻译”第一反应是“芯片里跑个翻译模型”。做产品不能这么想问题，得看成本约束。
我们评估过端侧方案的物料成本，光NPU模组就要比普通蓝牙音频芯片贵不少，还要额外配大容量Flash和DDR，整机功耗也会上去。而一颗蓝牙音频SoC自带ADC、蓝牙射频、音频Codec、电源管理，外围加个麦克风、喇叭和电池就能出声，BOM成本优势是压倒性的。
翻译场景还有一个特点：语言对太多。中英、中日、中韩、英法……如果每个语言对都要在端侧跑模型，存储空间和内存都是灾难。云端方案只需要一个云端接口，无论多少语言对都只是换个参数的问题。后续维护也变得简单，云端识别率提升了，用户手里的硬件不用动，体验自动变好。
当然，端侧方案不是没有价值。离线翻译在无网环境、隐私敏感场景下是刚需，但那属于另一类产品，目标用户和成本结构完全不同。我们做的是走量型消费电子，选云端无可争议。
1.3 从麦克风到扬声器的完整链路
我把整个链路拆成六段来讲，后面所有问题排查都围绕这六段展开：
- 第1段：耳机上的麦克风阵列采集说话人语音，经过板载的降噪、回声消除处理，输出干净的16kHz/16bit PCM数据。
- 第2段：这部分PCM数据通过SPP通道打包发给手机App，每帧20ms，一帧640字节。
- 第3段：App收到音频帧后，先做VAD检测和预加重，送入云端的ASR服务，拿到带标点的时间戳文本。
- 第4段：ASR文本送到云端MT引擎翻译成目标语言文本。
- 第5段：翻译结果文本交给TTS引擎合成语音，返回PCM或MP3数据。
- 第6段：App将合成语音经A2DP推送回耳机播放，用户听到翻译结果。
这六段里，第1、2、6段由芯片固件负责，第3、4、5段由App和云端负责。刚开始设计时，我觉得芯片端的工作很少，不就是采集和播放吗？真做起来才发现，恰恰是这两头最简单、最容易翻车，后面我会详细说。
2. 核心细节与关键技术
2.1 蓝牙链路的取舍：HFP与A2DP都不适合直接硬套
同声翻译对蓝牙链路的第一个要求是：上行要有干净的语音数据，下行要有流畅的音频播放。听起来很简单，但蓝牙协议里没有一个Profile是专门给“实时翻译”设计的。
HFP是免提协议，天生就是双向语音，支持上行麦克风数据和下行听筒音频。但它有两个硬伤：采样率被压到8kHz，编码方式是CVSD，语音质量比较差，直接喂给ASR，识别率会明显下降。虽然有宽频HFP能到16kHz，但它在很多手机和耳机组合下兼容性不一致，实际调试中吃了不少苦头。HFP第二个硬伤是SCO链路带宽小，无法承载高质量TTS音频，播放出来的合成语音闷闷的。
A2DP是音乐播放协议，能跑高码率音频，音质没问题。但它只支持下行播放，没有上行麦克风通道。也就是说，你想把用户在耳机这边说的话发到手机，A2DP帮不上任何忙。
所以最终方案是组合拳：上行语音不走HFP，而是由芯片的ADC采集PCM，通过SPP自定义通道发送给App；下行TTS走A2DP播放。这样上行音质完全由自己控制，下行也能保证播报清晰。代价是自己要处理一部分音频封装和传输逻辑，但相比HFP的不可控，这点工作量完全值得。
2.2 语音前处理：降噪、回声消除和端点检测
同声翻译耳机最常见的场景是嘈杂公共场合，比如机场、展会、餐厅。如果麦克风直接拾取原始音频送到ASR，识别结果会惨不忍睹。我实测过一句话在70分贝环境噪声下的识别率，直接从95%掉到不到60%，所以前处理不是可选项。
芯片端我们做了三件事。
第一，双麦降噪。耳机上有两颗麦克风，一颗指向嘴巴做主拾音，一颗朝外采集环境噪声做参考。两路信号做差分处理，能明显压低环境噪声。这里要注意麦克风在耳机上的相对位置，主麦和辅麦距离一般在15到20毫米，太近了差分效果差，太远了两路信号相关性不足。
第二，AEC回声消除。如果不做AEC，TTS播放的声音会被麦克风重新采集，形成回声，导致识别出现自己声音的重复内容。AEC的参考信号直接取芯片的DAC输出，也就是自己播出去的那路音频，实时做自适应滤波抵消。这一步必须在芯片端做，App端拿不到原始的DAC参考信号，没法补偿。
第三，VAD语音端点检测。芯片检测到没有有效人声的帧，直接不上传，让App端保持空闲，节省云服务调用成本，也降低整机功耗。VAD阈值要仔细调，太灵敏会把背景音乐当成人声，持续触发上传；太迟钝会吞掉说话的起始部分，导致ASR把第一个字识别丢。
实操中我用过一个简单有效的VAD判定：基于短时能量+过零率。人声的过零率比环境噪声低，但能量起伏大。设置两个阈值分别判断能量和过零率，同时满足才认为有人声。这个算法在芯片上跑几乎不占资源，效果也还不错。
2.3 与App的协议设计：控制信令和音频流分开走
同声翻译耳机和App之间的通信，我们一开始犯过直接在一个通道里既发控制指令又发音频数据的错误。结果就是音频数据稍微一多，指令就卡住；指令优先处理，音频就出现断续。后来彻底改成双通道设计，各管各的。
控制信令走一个SPP连接，格式是JSON行协议，每条指令一行，如：
{"cmd":"start_translate","src":"zh","dst":"en","mode":"dual"} {"cmd":"stop_translate","req_id":1234} {"cmd":"tts_play","text_id":5678,"audio_type":"mp3"}音频流走另一个SPP连接，纯二进制流，不掺任何控制信息。每包20ms，固定640字节的16bit/16kHz PCM数据，包头加一个2字节的序号和4字节的时间戳，方便App端检测丢包和处理延迟。
为什么要把格式设计得这么简单？因为消费类电子产品的App要和多种硬件版本兼容，协议越简单越不容易出错。复杂的二进制结构容易因字节对齐问题导致解析失败，JSON虽然体积大一点，但可读性和兼容性最好，出了问题抓包一看就明白。
3. 实操过程与核心环节实现
3.1 SDK环境搭建和工程初始化
这套芯片的SDK是典型的嵌入式工程结构，代码量不小，但目录逻辑还算清晰。核心是四个部分：芯片寄存器定义、外设驱动库、蓝牙协议栈、应用层Demo。
拿到SDK后，我做的第一件事不是写需求功能，而是先把芯片的麦克风通路上电，用ADC采集一段原始语音，通过串口打印PCM的幅值。这一步叫“通水路”，确认硬件连接和音频通路正常。很多问题的根源都在硬件连接上，比如麦克风正负极焊反、偏置电阻没贴、差分输入接成了单端，不提前查清楚，后面写再多代码都是白搭。
工程配置里需要注意采样率设置。翻译场景我建议配置成16kHz单声道。为什么不是44.1kHz？翻译用不到那么高的带宽，16kHz对ASR已经足够，高采样率只会增加蓝牙传输数据量和芯片功耗。44.1kHz是用来听音乐的，不是用来识别的。
3.2 音频采集与上行传输实现
芯片端的主循环里，音频采集通常由DMA中断驱动，采集到完整一帧后触发回调。我在这套方案里定义了一个PCM回调函数，伪代码大致是这样：
static void pcm_callback(int16_t *pcm, uint32_t sample_count) { // 1. 运行降噪和前处理 audio_preprocess(pcm, sample_count); // 2. 运行VAD检测 if (vad_predict(pcm, sample_count) == VAD_SPEECH) { // 3. 组帧并通过SPP发送到手机 uint8_t packet[644]; build_audio_packet(packet, pcm, sample_count); spp_send(SOCKET_AUDIO_UPLINK, packet, sizeof(packet)); } }注意，这里的音频发送不能用阻塞式接口。SPP发送是异步的，如果阻塞等待发送结果，DMA回调就会被卡住，造成音频采集溢出。正确做法是把待发送的数据排入环形队列，由协议栈自行调度发送，DMA回调里只做入队操作。这个细节如果没处理好，整机会出现周期性卡顿。
3.3 蓝牙链路建立与回连处理
蓝牙配对流程在SDK里是现成的，但回连逻辑要自己打磨。翻译耳机和普通蓝牙耳机不同，用户很可能今天换了台手机用，明天又用回原来的手机。我们维护了一张已配对设备的列表，启动后按优先级尝试回连：最近使用过>历史使用时间最长>首次配对成功。实测这种做法在用户换机场景下不会卡死在原地。
还有个容易忽略的问题：当耳机已经连上手机A，用户再拿出手机B时，系统会自动断开A去连B，还是保持静默？翻译耳机的最佳体验是“谁解锁手机并打开App，就切给谁”，但单纯靠蓝牙的音频协议很难判断“哪个App在前台”。我们在App端做了一个主动切换机制：App启动后检查当前蓝牙连接是否属于自己的耳机，如果不是，主动发起连接申请。这一层逻辑写在App端，比写在芯片端灵活得多。
3.4 翻译链路联调与端侧播放
联调分三步走。
第一步，验证上行。让测试者对着耳机麦克风说一段固定文本，App端把收到的PCM存成WAV文件，人工检查录音质量。这一步通过后，再交给ASR识别，看识别率是否达到预期。
第二步，模拟下行。App端不接真实翻译引擎，先用一段本地TTS音频通过A2DP推送给耳机，检查播放是否连续、有没有爆音、能不能听到清晰的翻译内容。
第三步，云端全链路。接上真实ASR、MT、TTS服务，从说话开始计时，到耳机播出翻译结果截止，记录端到端延迟。
延迟测试我建议用音频注入法，比人工掐秒表准确得多。在安静环境中播放一段录制好的混合语音——人声旁边垫一个1kHz的定位音标。App记录定位音标的到达时刻，耳机端麦克风会同时拾到定位音标的声学信号和TTS播出的信号。通过分析两个信号的相对时间差，就能精确测得延迟。
3.5 延迟优化实测
我第一次测试全链路延迟，结果吓一跳，达到了1.8秒，完全不像“同声翻译”。逐段排查发现，问题出在四块。
第一，手机App的音频采集缓冲区默认设了200ms，用于防抖，但对实时翻译来说太长了。调整为30ms后，上行延迟减少明显。第二，云端ASR拿到的是整个音频文件，而不是流式音频，必须说完整句话才能识别。换成流式ASR接口后，ASR首包返回时间从600ms降到180ms。第三，TTS合成策略也优化过，从一次性合成整句改为流式合成，边合成边播放。第四，耳机端播放缓冲区从300ms降到80ms。这几处调完，端到端延迟稳定在900到1100ms之间，体验上基本能承受。
4. 常见问题与排查技巧实录
4.1 翻译结果回传延迟突然变大
这个问题我们排查时间最长，现象是刚连上前几分钟正常，十分钟后延迟越来越重。查到最后是手机App里后台的音频缓冲队列堆积了。原因是蓝牙射频在重负载下会触发丢包重传，A2DP的流量控制机制在弱信号时会把数据积压，App这边按固定节奏往队列里塞数据，没注意到蓝牙发送端已经出不去。
解决方法是App端做一个动态缓冲策略：统计最近10帧的发送耗时，如果明显大于预期，就主动丢弃队尾的旧数据，保证播放的是最新内容。这个策略在翻译场景下是正确的，因为翻译结果有时效性，用户不需要听10秒前的翻译。
4.2 麦克风拾音音量小导致识别率低
硬件上检查了一圈，麦克风本身没问题，增益也调到了合理范围，但识别率就是上不去。后来发现是蓝牙SPP发送的数据出现了字节序不一致。芯片端是小端存储，App端解析时用大端读取，导致每一帧的幅值都被解析成接近静音。这个问题极具迷惑性，因为波形文件用非专业工具打开时，由于幅值低，看起来只是音量小，不容易联想到字节序。
排查方法很简单：在芯片端发一个已知幅值的正弦波，App端抓包后看幅值是否一致。如果差了一个数量级，十有八九就是字节序或者位深解析不匹配。
4.3 双耳耳机左右声道串话
双耳翻译耳机方案里，每只耳机各有一颗麦克风，分别负责一个说话人。比如A戴左耳，B戴右耳，A说话走左耳声道，B说话走右耳声道，翻译时还要把结果送给对方耳机。这类产品的左右声道必须严格隔离，否则两人同时说话，上行语音就会混在一起。
我们遇到的问题是物理串话，不是软件问题。耳机左右声道在排线上靠得太近，麦克风信号线受到的串扰大于人声音量。解决方法是PCB走线时把麦克风差分对做包地处理，并在软件端加入了左右声道独立VAD，只有本侧检测到人声时才启动本侧的上行传输，另一侧保持关闭。
4.4 整机待机功耗异常发热
做第一版固件时，整机待机电流明显偏高，外壳能摸到温升。查下来是麦克风偏置电路始终在上电状态，ADC也保持常开，即使没有语音也在不间断运行。同声翻译耳机要求“随时能听”，但不是说ADC要永远满速跑。
优化方案是分级电源管理：VAD检测器用低功耗协处理器跑，持续工作，但ADC和蓝牙在无语音时进入低功耗模式，只在VAD触发说话时才唤醒全链路。优化后待机电流从28mA降到了3mA以内，挂脖耳机用两块200mAh电池也能支撑一整天的翻译使用。
4.5 新手容易踩的几个操作坑
总结一下整个项目里最容易让人翻车的几个点。
第一个坑是SDK配置里把DMA缓冲设得过大。很多人觉得缓冲大不容易丢数据，但在实时音频里，缓冲大等于延迟高，得不偿失。DMA缓冲保持一帧即可，比如20ms一帧，就配20ms缓冲。
第二个坑是A2DP和SPP同时工作时，信道调度没有优先级。蓝牙射频资源是共享的，音频流大时SPP的音频帧被挤压，导致上行丢包。我们在SDK里把SPP的发送优先级调到最高，并限制下行TTS的码率，实测丢包率低了很多。
第三个坑是模组天线布局。天线靠近麦克风走线后，射频干扰会直接耦合进音频通路，产生“滋滋”声。改版时把天线和音频走线分开，问题消除。嵌入式产品里很多所谓“软件BUG”最后都查到了硬件布局上，越早layout review越省钱。
5. 这批方案做完后的几点实操体会
最后再分享几个这次项目中沉淀下来的经验。
第一，同声翻译类产品，硬件端要做到的其实是“可靠地把声音传出去、播出来”，真正的难点在链路稳定性和延迟控制上，而不在翻译算法本身。芯片端能做的降噪、VAD、缓冲控制，每一环都会直接影响云端识别的效果，千万不要觉得云端算力强就能弥补前端采集的粗糙。
第二，调试时一定要分点验证，不要直接跳全链路测试。我的习惯是先把每一段做成可独立观测的模块：芯片端能通过串口打印PCM幅值，App端能实时存储音频片段，云端接口能单独跑模拟数据。哪一段出问题，当场就能圈定范围，不用靠猜。
第三，翻译耳机这类设备的延迟目标，业内还没有统一标准，但根据我这个项目实测，把端到端控制在1.2秒以内是基本门槛，1秒以内算良好，低于800毫秒就是接近“同声”了。再往下抠延迟，收益会明显递减，容易牺牲稳定性和续航，产品上不划算。
这套方案的真实体验是，中英文短句对话场景下，双方基本能做到“对方说完话后等一小下就听到翻译”；长句或复杂句式受云端算法影响会慢一些，但作为消费级产品已经具备可用性。后续如果要做升级，可以考虑在App端加入离线热词、自定义词汇库，以及针对具体行业场景的术语模型，这些都不需要动硬件，迭代成本极低。
就这些，希望能给正在折腾同声翻译硬件的朋友一点参考。
