最近不止一个人问过我同一个问题“我做个设备不需要通过蓝牙放手机里的歌只想让手机APP通过蓝牙给设备发个指令然后设备把自己本地存好的语音播出来这种该选哪颗国产芯片”这个问题看着简单其实里面藏着两个坑一是把“蓝牙BLE透传”和“蓝牙音频”混为一谈二是把“本地语音播报”想成必须靠云端识别才能做。把这俩弄明白选型基本就出来了。下面我会直接给出我的答案再把从硬件到固件的完整落地流程拉一遍。无论是做测温枪、语音提示器、智能家居小网关还是给孩子做的语音学习设备这篇文章的思路都能直接用。1. 先把需求看清楚你的设备要的到底是哪种“蓝牙”和哪种“语音”1.1 为什么很多人一开始就把方向选错了“蓝牙听歌”和“BLE透传”是两个完全不同的技术方向这是选型时最容易被绕进去的地方。蓝牙听歌走的是A2DP高级音频分发协议和HFP免提协议这类协议要求持续的数据流、低延迟、双向同步相当于是“给音频信号专门修了一条高速公路”。所以主打听歌的蓝牙耳机、蓝牙音箱所用的SoC研发重心都放在音频编解码、DSP音效、降噪算法上。这类芯片能做BLE透传吗能但很多型号只是“附带支持”广播参数、连接间隔、透传吞吐率都不是强项。而BLE透传本质上是“小包裹快递服务”。它走GATT通用属性协议把数据拆成一个个小包强调连接建立快、待机功耗低、传输可靠。心率计、温湿度传感器、体脂秤、标签打印机、智能门锁这些都是典型BLE透传设备。它们偶尔发几个字节根本不关心音质。很多工程师一开始下意识按“蓝牙音频芯片”去搜结果买回来的芯片方案里全是音频DSP、EQ调节、TWS对箱、A2DP音频流这些你用不上的功能开发成本反而被拉高了。反过来如果你只盯着低功耗BLE Mesh这类芯片又会发现很多纯BLE SoC连DAC都没有语音播报做不了。所以第一步先把需求钉死你要的是“数据蓝牙”加“本地发声”不是“音频蓝牙”。1.2 “本地语音播报”到底是怎么个播法本地语音播报这个词很多人一听就想到“语音识别”其实这里分三种做法成本差很多。第一种是预置音频播放。也就是把“欢迎使用”“温度正常”“电量低”这类固定话术提前转成音频文件存进Flash收到BLE指令后芯片读出来送到DAC播放。这是最实用、成本最低、可靠性最高的方案。标题里说的“本地语音播报”绝大多数情况就是这种。第二种是离线TTS也就是芯片自己把文字合成为语音比如“当前电量百分之八十五”这种动态内容数字每次都不一样没法提前录音。这种需要额外的TTS引擎和算力一颗带音频播放能力的MCU通常跑不动得用专门的离线语音识别芯片比如启英泰伦一部分型号或者外挂一颗带TTS功能的语音芯片成本明显上去了。第三种是外挂语音模块BLE MCU收到指令后通过UART/GPIO通知一个独立的语音播报芯片比如市面上常见的OTP语音芯片、Flash语音模块。好处是BLE和语音完全解耦坏处是板子上多一颗芯片、多一路供电、多一段调试工作适合你对BLE链路功耗和稳定性要求特别高、但又不想主控芯片被音频占资源的情况。我看到这个标题的第一反应就是第一种。所以后面所有选型、实操都围绕“BLE透传 本地预置音频播放”来做。如果你的项目确实需要离线TTS看我的选型表时注意避开不带TTS库的芯片。1.3 选型前先列四张表才不会翻车我不建议直接看型号先把自己的需求量化了再去看芯片。我一般会让朋友先回答下面四个问题。第一音频怎么出去。芯片有没有DACDAC是单声道还是立体声能不能直推喇叭还是需要外挂功放如果芯片本身只有I2S输出你还得配一颗音频DAC或者Class-D功放成本、面积都上去了。第二语音存在哪里。一段10秒的语音用8kHz采样、16bit单声道WAV大约160KBSD卡方案不现实基本都是把语音压进SPI NOR Flash或者用芯片内置Flash。如果你的提示音超过几十段、每段又长Flash容量就直接决定型号选择。第三BLE透传怎么用。是UART透传手机端装个串口助手下发十六进制指令还是自定义GATT服务App端通过特征值读写前者SDK越简单越好后者也得确认芯片SDK里二次开发接口开放度够不够。第四量产条件如何。原厂工具链、烧录器、量产测试软件是不是容易搞到文档是全中文还是只有英文BOM成本目标是多少这几点别等画完板子再考虑尤其是国产芯片不同原厂的服务响应差距非常大。2. 芯片选型目前能打的国产方案放在一起比一比2.1 国产BLE加音频SoC的主力梯队能“一颗芯片同时搞定BLE透传和本地语音播报”的国产方案目前我接触下来有三家最常被点名另有两家属于“特定场景也可以用”的备选。第一是珠海杰理。杰理在点读笔、语音玩具、蓝牙音箱市场占有率很高很多做测温、压感笔、智能语音提示器的方案商都在用。它的AC69XX系列和AD69XX系列自带DAC和功放支持蓝牙双模SDK里既能把A2DP关闭只保留BLE透传又能通过提示音接口直接播放本地音频非常符合本标题的场景。你随便搜“AD697N 测温仪方案”就能看到大量现成参考设计。第二是中科蓝讯。它的AB5系列主控同样是双模蓝牙常见于TWS耳机、蓝牙音箱、遥控器、语音玩具。相比杰理中科蓝讯在音频校准、RF性能上有些自己的优势SDK里也能做BLE透传但早期很多资料需要签NDA才给全个人开发者上手会稍微绕一点。现在正通过代理商放出来比以前好多了。第三是炬芯科技。它的ATS28系列性能更强部分型号支持DSP处理、环境噪声消除、更丰富的I2S接口适合对音质有要求或者需要跑复杂音频算法的产品。缺点是价格和开发门槛都高一些如果产品只是“滴一声播一句话”用炬芯有点杀鸡用牛刀。另外还有泰凌微和乐鑫这两个常被误拿来做语音播报的。泰凌微TLSR8258这类是低功耗多协议MCUBLE是真强、待机功耗是真低但不带DAC语音必须外挂模块。乐鑫ESP32-C3也能做BLE转发、I2S音频可是它带WiFi待机功耗明显高而且本地模拟音频输出基本要外接DAC严格来说不是这个场景的第一选择。2.2 核心参数横向对比我把目前我实际接触过、身边方案商也在用的国产型号整理成一张表方便你直接复制到自己的选型报告里。价格是参考量级的别当报价用不同Flash配置和供货行情差别很大。方案型号厂家蓝牙能力音频输出语音方案典型成本区间参考开发难度适合场景AD697N / AC6969B杰理双模BLE透传成熟内置DAC、可直推喇叭本地WAV/MP3播放无TTS2~4元中低方案资料多测温、语音提示、点读笔、小家电AB5356A / AB5301A中科蓝讯双模内置DAC支持本地音频部分有音效算法2~4元中需要签协议蓝牙音箱、语音玩具、遥控ATS2831P / ATS2853炬芯双模内置DAC/I2S本地音频DSP能力强5~8元中高智能音箱、桌面设备、语音交互TLSR8258泰凌微单模BLE为主无DAC需外挂语音模块1.5~3元不算语音芯片中传感器、灯控、低功耗数据采集ESP32-C3乐鑫BLEWiFiI2S无模拟输出需外挂DAC/语音模块5~8元低智能家居原型、物联网网关这里面有一个隐藏指标就是内置DAC。杰理、中科蓝讯、炬芯这几颗都是直接带DAC的喇叭可以经过一个简单RC滤波、再接功放驱动不需要额外音频解码芯片。对于“本地语音播报”这个需求来说DAC就是那个“我很合适”的标记。没有DAC的芯片就算BLE性能再好你也得在边上再塞一颗语音芯片BOM和开发成本马上不一样。2.3 顺带澄清一个热搜词国产百兆PHY芯片跟这个需求没关系写这篇文章之前我顺手看了眼相关热词发现“国产百兆PHY芯片”也跟着上榜了。这里必须给同行提个醒完全是两个赛道。百兆PHY芯片是以太网物理层芯片主要用在交换机、路由器、工业网关、IPC摄像头这些有RJ45网口的设备上它是处理网络信号收发的跟蓝牙射频、语音DAC一点关系都没有。如果你是在做带网口的联网设备那可以去看国产PHY芯片但标题里这个“BLE透传加本地语音播报”的便携式设备对应的是蓝牙SoC别被搜索引擎的热搜词带跑偏。我见过不止一个朋友在搜“蓝牙语音芯片”时被推荐了网络PHY芯片差点规划错方向。2.4 我给选型拍板的顺序如果让我直接给结论我会这么分三档。第一档预算敏感、语音内容固定、量产压力大选杰理AD697N或者AC6969B这一档。理由是成本足够低、DAC直推、SDK里BLE透传和提示音播报都是现成模块开发周期能压到一两周。第二档如果产品除了语音播报还要做多段音频切换、音效处理、录音回放或者蓝牙配对体验想做得更细那就看中科蓝讯AB5356A或炬芯ATS2831P。前者性价比均衡后者性能和资源更宽裕。第三档如果是低功耗传感器、靠纽扣电池供电、BLE连接频繁但每次数据量很小语音只是偶尔“滴”一声或者播个短提示那就别硬用音频SoC用泰凌微TLSR8258做BLE主控再外挂一颗很便宜的语音播报芯片整体功耗和成本反而更好控。3. 实操过程拿AD697N跑通一个最小demo3.1 硬件准备和最小系统接线我习惯用杰理方案做这种快速验证原因是它的SDK里“BLE透传按键触发语音”的例程基本是现成的。这里拿AD697N这一档做示例你也完全可以换成同系列其它型号。你需要准备的东西不多一颗AD697N或AC6969B的核心板或者直接买杰理方案的蓝牙语音模组一个小喇叭阻抗4欧或8欧都行最好带线的那种一个USB转串口工具用来烧录和打印日志杰理原厂的烧录器代理商处一般几十块能买到这是必需工具一个SPI NOR Flash容量看你的语音素材长度我一般用8Mbit也就是1MB起步3.3V稳压电路最好用LDO不要用DCDC直接给音频部分供电底噪会小很多硬件接线并不复杂喇叭接在DAC输出引脚上中间加一个RC低通滤波再加一个功放芯片低成本可以用8002A这类如果不追求音量DAC直推蜂鸣器或者小喇叭也能响只是声音小。Flash接SPI接口芯片启动后从里面读语音数据。这里有一个我反复踩过的坑供电纹波对DAC底噪的影响极大。用同一个LDO给数字部分和模拟音频部分供电时BLE发射瞬间电流抬升会在电源上产生毛刺喇叭里就会听到“滋滋”声。解决办法是把音频供电单独用一颗LDO或者至少靠近DAC引脚加一个100uF电解电容和0.1uF陶瓷电容并联。3.2 配置SDK关掉蓝牙听歌只留BLE透传从代理商那边拿到杰理SDK之后第一件事不是写代码而是打开原厂提供的配置工具把工程能关掉的蓝牙音频功能全关掉。在工具里找到蓝牙profile配置项把A2DP和HFP去掉。很多参考工程默认是“蓝牙音箱”模式会占用很多内部资源去维护音频链路而我们的需求里手机根本不推歌留着这些协议只会增加功耗和代码复杂度。同时打开BLE透传功能配置广播名称、连接间隔、MTU尺寸。接着配置透传通道。杰理SDK里通常提供一个“BLE UART透传服务”手机通过GATT特征值向设备写数据设备再把收到的数据原样扔给串口或者反过来把串口数据发到手机。这个服务拿来就能用但你至少要确认三件事读写特征值的UUID、最大数据包长度、收到数据后有没有回调函数可以把数据转发到应用层。如果不想用系统自带的透传服务也可以自己定义一个GATT Service把收到的数据在回调里解析成指令。比如定义指令“0x01代表播放1号语音”“0x02代表播放2号语音”这样比直接透传一串字符串更稳定也更容易对接你自己的App。3.3 语音素材处理和触发播报逻辑语音素材的格式是整个项目最容易“差不多就行”、最后又返工的地方。先说我的推荐配置音频转成8kHz采样率、16bit位深、单声道WAV或者直接用SDK支持的ADPCM格式。为什么不用44.1kHz高音质因为语音播报场景是“人声短句”8kHz的语音清晰度完全够用而文件体积只有CD音质的约六分之一Flash成本和读取压力都小很多。一段10秒的播报8kHz、16bit、单声道WAV大概是160KB。如果你用ADPCM压缩能再缩到五分之一左右。所以我一般把固定提示音控制在5秒内这样即使只配1MB Flash也能存下二三十段语音对大多数产品绰绰有余。音频处理好之后在SDK的资源管理工具里建立语音列表每段语音对应一个索引号。然后在BLE收到指令的回调里做switch-case收到对应指令就调用播放接口。就这么简单不需要自己写音频解码器芯片SDK已经把播放流程封装好了。有一点要提醒不要在播报过程中再反复触发播报接口容易造成播报卡顿或者串音。正确做法是加一个“当前是否正在播报”的状态判断播报期间把新指令缓存起来播完再处理。3.4 编译烧录和手机端验证代码整理好之后就是烧录验证。杰理方案的烧录一般通过原厂工具完成先把固件和语音资源打包生成烧录文件再用烧录器把合并后的镜像写进Flash。这里注意如果你改了语音素材不只是重新编译固件还要把资源文件一起打包不然运行时会找不到语音。上电后用手机做测试。我推荐nRF Connect这个蓝牙调试工具不需要自己先写App。扫描到你的广播名连接设备找到透传服务在特征值上写入指令比如写“0x01”喇叭就应该能播出对应语音。同时打开串口工具看日志确认收到数据、播报状态切换是否正常。我实测下来第一次跑通大概只需要半天。这里说个细节如果写数据没反应先别急着怀疑代码看看是不是手机端写了“没有写权限”的特征值。BLE服务里有Read、Write、WriteWithoutResponse、Notify等属性透传服务需要往有Write权限的特征值里发数据才行。我在nRF Connect里就经常习惯性地点到Read特征值上半天没反应其实就是属性搞错了。4. 常见问题与排查技巧4.1 BLE连接不稳定、经常断连这类问题十个里有八个不是芯片性能差而是广播参数或者天线匹配没弄好。先看广播间隔。如果广播间隔太短芯片会一直处于高功耗发射状态电源不稳时会直接导致射频失联如果太长手机扫描到设备变慢体验就“卡”。室内产品我一般用100ms到200ms户外低功耗设备可以把广播间隔拉到1秒以上代价是App连上设备要等更久。再看天线。很多朋友用模组以为天线就稳了但天线周围铺铜、外壳材质、喇叭磁铁位置都会影响蓝牙灵敏度。如果你的设备里正好有喇叭喇叭磁铁离天线太近会把蓝牙信号吸得很惨。解决办法是让天线远离喇叭至少保持5mm以上距离或者在结构上做天线净空区。最后看电源瞬态。BLE连接后芯片发射电流可能瞬间冲到几十毫安如果供电网络内阻大电压跌落就会让芯片射频链路复位。排查方法很简单用示波器看芯片供电脚的波形连接瞬间有没有明显跌落有就加大储能电容。4.2 播报卡顿、爆音、底噪明显播报卡顿先怀疑Flash读取。如果语音资源放在SPI Flash里Flash质量不好或者SPI时钟设置太高读取就会偶尔失败表现就是声音“咔哒”一下。解决方案是把Flash的SPI时钟降一档或者换成更稳定的Flash型号。爆音常出现在播放启动和结束的瞬间。这是DAC输出在未初始化完成时被直接使能造成的瞬态冲击。在代码里加一个“先打开DAC和功放延时几百毫秒再开始播放”的流程结束播报时也先停止数据再延时关闭功放体验会好很多。底噪的问题得区分是传导噪声还是辐射噪声。前面说的电源LDO隔离解决的是传导噪声辐射噪声则要检查喇叭线和DAC信号线是不是跟BLE天线靠太近。我见过一个案例喇叭响的时候测蓝牙传输质量误码率明显上升最后发现是喇叭线成了天线把噪声带进了射频通路。换成双绞后问题消失。这类问题在现场特别难查最好是第一版PCB就把喇叭走线、音频线、天线区域规划清楚。4.3 待机功耗怎么都压不下来很多国产蓝牙SoC标称功耗都很低但实际待机电流居高不下多半是没进睡眠模式。本地语音播报和BLE透传场景设备大部分时间应该是“睡着”的BLE广播可能开着也可能关掉等外部事件唤醒再连接。如果你发现待机电流有几十毫安级先看是不是外部的Flash在一直空读、功放芯片没有关断、LDO静态电流太大多数情况下罪魁祸首是功放而不是主控芯片。如果把功放的使能脚接到主控GPIO不进播报状态就拉低待机电流能直接降一个数量级。另外提醒一下杰理这类SDK默认工程可能把LED灯、串口打印、按键扫描都开着这些在量产里都是漏电点。记得在睡眠代码里把所有外设逐个关掉再测电流。4.4 Flash空间不够用了语音内容多Flash塞不下这是做提示类产品经常遇到的问题。我按优先级给你几个招。第一压缩音频格式。从WAV换成ADPCM体积能缩到五分之一失真对于语音播报基本听不太出来。第二降低采样率。6kHz采样的人声短句其实也能听懂只是略闷。第三共享公共语音。比如“设备正在”和“运行中”可以拆成两段按顺序播放避免录一整条长句。第四实在不行再加大Flash容量从1MB换到2MB成本增加很小。这里有个容易忽略的点芯片的Flash地址映射范围是有上限的不是想加多大就加多大。换Flash之前先翻SDK手册确认当前那颗芯片能寻址的最大容量别买了大Flash结果只认一半。4.5 国产芯片选型里的“隐形坑”最后说几个我实际踩过、不想你再踩一遍的坑。第一原厂SDK的授权协议要看清。有些芯片商对二次开发收取授权费或者限制出货量这直接决定你的产品成本结构。第二烧录器和量产测试工具是否好买。你选了一颗价格很好的芯片结果烧录器要等两个月产线就卡死在那里。第三技术支持响应速度。越热门、量越大的方案代理商和原厂的FAE越熟你问一个问题当天就能有答案冷门芯片可能连开发板资料都要自己拼凑。所以我一直建议个人开发者和中小公司选芯片不是在选“性能最好的”而是选“出问题后你能最快搞到答案和帮助的”。这也是为什么很多中小产品都喜欢扎堆用杰理、中科蓝讯、炬芯这类主流国产方案——不是它们没有缺点而是你自己啃SDK的沟别人已经帮你填平了。我个人在这类项目上的体会是需求越简单越要用“大路货”芯片和方案别为了省两块钱选一颗自己完全没把握的型号。BLE透传和本地语音播报这个组合技术栈其实很成熟了真正的成本都花在电源、天线、喇叭这些“看起来不起眼”的地方。你把这几块弄扎实再普通的国产芯片都能做得又稳又省电。如果后面有时间我再把离线TTS方案和更低功耗的外挂语音模块方案整理出来那个场景又能玩出不少花活。