简介：面向智能音箱、物联网等音频产品开发者的AC108多麦克风阵列驱动芯片资料合集，涵盖从芯片选型到驱动适配的完整环节。资源共23个文件，以PDF规格书（datasheet、硬件设计指南、用户手册）、原理图工程文件（DSN/SCH/OPJ）以及驱动源码（H/C文件）为主，压缩包约11.97MB，结构按brief、datasheet、硬件指南、参考原理图、驱动说明等模块组织。已有969人学习下载。通过这套文档可系统掌握AC108的电气特性、引脚定义、I2C/SPI控制接口配置、多路ADC采样与噪声抑制功能，并参照EVB参考原理图完成麦克风阵列电路设计；驱动说明中的API接口与示例代码，也能帮助开发者快速完成Linux或其他嵌入式平台下的驱动集成与调试。适合正在做多麦克风阵列、语音识别前端硬件设计的工程师参考。
1. 项目背景：这颗“多mic矩阵驱动芯片”到底是什么来头
第一次拿到“AC108，多mic矩阵 驱动芯片设计相关文档”这个需求的时候，我第一反应是：这又是哪个方案商把“麦克风阵列采集芯片”和“驱动芯片”这两个概念揉在一起了。实际看下来，AC108并不是传统意义上那种“驱动芯片”——它不驱动喇叭、不驱动电机、不点灯，它的本质是一颗4通道的音频ADC模拟前端，专门用来把多路数字麦克风（主要是PDM接口的MEMS麦）的信号转成I2S/TDM数据流，送给主控芯片去做语音处理。
我在实际项目里接触这颗芯片，是因为当时在做一套6麦环形阵列的语音交互模组。主控是瑞芯微的RK3568，跑Linux系统，需要采集6路麦克风做波束成形和回声消除。市面上做4通道ADC的芯片不少，但AC108在这个场景里比较有代表性：单颗支持4通道PDM输入，输出走I2S/TDM，最多可以级联两片实现8通道。对做智能音箱、会议麦克风、机器人语音交互的人来说，这套“多mic矩阵采集方案”几乎是绕不开的硬件基准。
这篇文档我尽量把话说透：AC108在麦克风矩阵里的定位、硬件电路设计要点、Linux下驱动如何对接、以及我在调试中踩过的坑。不管你是刚接触麦克风阵列的硬件工程师，还是被分配去调音频驱动的软件同事，都能从中找到可以直接抄作业的内容。
同时我注意到最新网络热词里有“led闪灯驱动芯片”“带数码管的风扇驱动芯片”。老实说，这两类芯片和AC108完全是两个物种——“驱动芯片”这个词放在LED灯和风扇场景里，指的是功率驱动、恒流源、PWM控制那一套；而AC108承担的是信号采集和格式转换。如果在选型阶段混为一谈，很容易买错物料。这篇文档也会顺手帮你梳理清楚这个边界。
2. 多mic矩阵的设计思路：为什么选AC108而不是其他方案
2.1 麦克风阵列对采集芯片的核心需求
麦克风阵列和单颗麦克风最大的区别在于：后续的波束成形、声源定位、去混响算法，全都依赖“多通道信号在时间上严格同步”。如果两路信号之间出现哪怕一两个采样周期的偏差，相位差就是错的，beamforming的效果会大打折扣。
所以，选阵列采集芯片，第一看通道数，第二看同步机制，第三看接口是否方便和主控对接。AC108这类芯片之所以在矩阵方案里吃香，是因为它把4路PDM麦克风的时钟和数据的同步在芯片内部解决掉了，对外只输出一路TDM数据流。主控侧不需要同时处理4路I2S，只需要按TDM时隙解包就行。这种架构对Linux alsa驱动和DMA传输都非常友好。
另外，PDM麦克风本身只有两根线（CLK和DATA），走线少、成本低，适合做密集型阵列。模拟麦克风方案不但每路都要放大电路和ADC通道，而且模拟走线对PCB布局要求极高——在6麦环形阵这种空间紧凑的场景里很容易翻车。AC108这类数字前端芯片的价值就是把“模拟前端+ADC+TDM串行化”打包成一颗物料，硬件设计的工作量直接少了一半。
2.2 和LED、风扇驱动芯片的本质区别
既然热词把“驱动芯片”带到了这个项目里，我还是想多说一句。LED闪灯驱动芯片的核心是恒流驱动、PWM调光、灰度刷新，输出的是功率信号；风扇驱动芯片的核心是电机换相、堵转保护、转速反馈，输出的是三相驱动波形。它们的共同点是“驱动外部执行器”，属于功率链路的末端。
AC108的工作链路刚好相反：它从麦克风采集微弱的数字脉冲流，做抽取滤波后将音频PCM数据通过I2S/TDM传给主控。它属于信号链路的源头，不是功率链路。说它“驱动”麦克风，其实只是提供PDM时钟，功耗极其有限。如果你在搜“驱动芯片设计相关文档”时带着LED驱动或风扇驱动的资料预期，建议先调整方向——声学前端芯片和功率驱动芯片的参数维度完全不同，后面设计电路时的参考系也不一样。
2.3 方案选型对比与取舍
我在确定方案的时候，其实对比过几个常见选项：双I2S接口的MCU直采方案、四通道模拟ADC方案、以及AC108级联方案。前两种要么通道数不够，要么模拟前端设计太重。AC108的优势在于它本身就是为“多mic”设计的，级联能力让它可以平滑扩展到8通道甚至更多。
具体到通道分配，我当时用的是两片AC108级联，一片负责麦克风0～3，另一片负责麦克风4～7，最后输出TDM8格式的数据流。这样主控侧只需要一个I2S控制器、一条TDM总线就能吃下8个通道，非常干净。
3. AC108核心细节解析与硬件实操要点
3.1 芯片关键配置与引脚功能
AC108的引脚不算复杂，但有几个关键点需要提前盯住：
- I2C地址：芯片上电后通过I2C配置，默认地址是0x4C（7位地址）。如果板子上挂多片，可以通过ADDR引脚调整地址，避免I2C总线冲突。
- PDM时钟与数据：每颗芯片有两组PDM输入，每组支持两路数据线（PDM_IN0/PDM_IN1），时钟由芯片内部产生，也可以由外部主控提供。多数情况下让AC108自己当主设备，输出BCLK和WCLK，这样省事。
- TDM输出引脚：I2S_OUT输出TDM格式数据，BCLK和WCLK既可以由AC108产生，也可以由主控作为master提供。两种模式我都试过，实际更推荐让主控做master，这样级联时时钟相位更容易对齐。
- 参考电压与电源：模拟部分建议用低纹波的LDO供电，数字部分和IO可以共用3.3V。参考电压引脚上的去耦电容不要省，我见过有板子因为这里少放了一颗0.1uF的电容，导致THD+N指标明显变差。
3.2 典型电路设计要点
一个典型的AC108多mic矩阵电路，大致可以拆成几个模块。我直接给一份我在项目中验证过的连接关系，方便你对照画图：
- 电源模块：3.3V LDO分别给AVDD和DVDD供电，磁珠隔离，退耦电容每引脚至少放0.1uF和10uF各一颗；
- PDM麦克风连接：每个麦克风的CLK并联到AC108的PDM_CLK，DATA分别接到PDM_IN0/PDM_IN1，注意麦克风的L/R选择引脚，决定它在这个时钟沿还是另一个时钟沿输出数据；
- 主控接口：I2C用于配置寄存器，TDM数据线连接到主控的I2S RX引脚，BCLK/WCLK由主控输出；
- 级联通路：如果两片级联，第二片的TDM输出通过一个简单的电阻网络合并到第一条TDM总线，或者在软件上配置第二片使用不同的时隙组。
这里我之前踩过一个坑：PDM麦克风的DATA引脚在PCB上不要走太长，也不要跨分割。这类数字信号虽然频率不高，但上升沿很陡，一旦走线过长，信号反射会造成采样数据偶发错误，表现就是语音里有“咔哒”声。初期打样可以把PDM走线控制在5cm以内，并且做好包地。
3.3 硬件设计中的常见细节坑
- TDM时隙冲突：级联时如果两片芯片的TDM时隙配置重叠，主控收到的数据会混在一起。解决方法是先读回寄存器确认配置，再用逻辑分析仪或者音频数据分析工具看每个时隙的内容。
- I2C地址冲突：如果板子上已经有其他I2C设备占用0x4C地址，记得通过ADDR引脚修改AC108的地址，否则上电枚举时会跳设备或者配置写失败。
- 参考电压的电容值不能随意换：有同事为了节省BOM，把参考电压的退耦电容从10uF改成1uF，结果底噪抬高了大概3dB。这类模拟性能相关的物料，严格按照规格书来是最稳妥的。
4. Linux下驱动设计与采集链路搭建
4.1 从ASoC框架理解AC108的驱动角色
在Linux音频框架里，AC108通常被实现为一个“codec driver”注册进ASoC子系统，尽管严格来说它是ADC前端，并没有DAC功能。对主控而言，这一侧的软件逻辑非常简单：通过I2C配置芯片，使其输出指定格式的TDM数据；主控侧dai_link配置为“CPU侧I2S控制器 ↔ codec侧AC108”，底层用dmaengine接收数据。
关键的dai_link配置大致长这样：
static struct snd_soc_dai_link my_board_dai_link = { .name = "AC108-MIC", .stream_name = "AC108-Capture", .cpu_dai_name = "i2s0", .codec_dai_name = "ac108-hifi", .codec_name = "ac108.0-004c", .platform_name = "rk3568-i2s0", .ops = &my_board_ops, };这里最容易搞混的是.codec_name的格式，要和设备树里i2c设备的label保持一致，否则probe阶段就会失败。很多人一开始写成AC108，系统根本找不到设备，直接报ASoC: failed to instantiate card。
4.2 设备树与TDM时隙映射
设备树里除了i2c节点，更重要的是设置I2S控制器的TDM模式和时隙数。AC108支持TDM4/TDM8，如果单颗芯片接4路麦克风，可以配置为TDM4模式，每个时隙对应一路麦克风；两片级联则配置为TDM8，前4个时隙给第一片，后4个给第二片。
设备树片段参考：
&i2s0 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2s0_lrck>, <&i2s0_bclk>, <&i2s0_sdo>; rockchip,tdm-mode = <1>; /* 1表示TDM模式 */ rockchip,i2s-tdm-slots = <8>; /* 8个时隙 */ };时钟配置方面，声卡的mclk一般取22.5792MHz或24.576MHz，44.1k和48k系列采样率可以分别对齐。AC108的主时钟优先级不高，实际项目中我更多是让它跟随I2S的BCLK来工作，减少一个时钟源的管理成本。
4.3 采样率与通道数配置
应用层通过ALSA录制时，需要让格式和芯片配置保持一致。比如8通道采样时，arecord的命令行参数要设置成：
arecord -D hw:0,0 -f S32_LE -r 48000 -c 8 -t wav capture.wavAC108内部会做PDM抽取滤波，输出的PCM格式是24bit还是32bit，取决于寄存器配置。我习惯统一输出为32bit宽度，但实际有效数据靠左对齐，这样DMA搬运和内存对齐都省心。需要注意的是，如果应用层用16bit格式录音，音量会偏低，因为数据的高位部分被截掉了，听起来就是“声音小外加底噪明显”。
5. 实操过程：从板子到手到稳定采集的完整记录
5.1 首次上电与I2C寄存器验证
板子打样回来之后，第一步不是跑系统，而是先用I2C工具确认芯片在线。先把设备树里的音频节点都关掉，只保留I2C控制器和AC108节点，然后在系统里执行：
i2cdetect -y 2正常情况下能扫描到0x4c这个地址。如果扫描不到，优先检查I2C上拉电阻和电源。接着用i2ctransfer读写一次寄存器，确认通信正常。AC108有个chip id寄存器，默认值应该是0x2860之类，具体可以参考规格书，最好读一次并记录下来，作为后续排查硬件的依据。
5.2 配置采集链路并验证数据正确性
I2C通信正常后，打开音频设备节点。先不要马上就跑算法，先用一条直白的录音命令抓一段环境声，保存成wav文件，然后在电脑上用Audacity或者Python的soundfile库看波形。更直接的方法是对着某个方向的麦克风说话，看对应通道的波形是否明显大于其他通道，以此验证通道映射是否正确。
实际操作中，我遇到过左声道和右声道对调的情况。原因是在PDM麦克风的L/R选择引脚上，我把左右两颗麦克风的设置接反了。解决方法是调换PCB上L/R的电平设置，或者在驱动层面重映射TDM时隙——不建议软件改时隙映射，因为会掩盖硬件问题，后续维护很痛苦。
5.3 级联模式下通道时隙的确认
两片AC108级联时，最容易出现的现象是：录下来8个通道，但只有4个通道有数据，另外4个通道全是静音或者重复数据。排查时直接读两片芯片的TDM slot配置寄存器，确认第一片输出slot0~3，第二片输出slot4~7。
如果时隙配置没问题，再看两片芯片的BCLK/WCLK是否来自同一时钟源。我在一个项目里遇到过两片芯片分别挂在两个I2S控制器上，各自产生时钟，结果采样率轻微偏差导致通道数据周期性错位。最后把级联模式改成“主从同步”，让第二片跟随第一片的时钟，问题立刻消失。
6. 常见问题与调试心得实录
6.1 典型问题速查表
| 问题现象 | 可能原因 | 排查方向 |
|---|---|---|
| I2C扫描不到设备 | 电源/上拉电阻/地址冲突 | 用万用表量AVDD/DVDD，检查上拉到VDD的电阻是否焊好，ADDR引脚电平是否被拉偏 |
| 录音全为静音 | PDM时钟没起来/时隙配置错 | 示波器量PDM_CLK，确认I2S的BCLK/WCLK波形，查TDM slot配置 |
| 部分通道无数据 | 麦克风L/R接反/时隙映射错 | 单独测试每颗麦克风的DATA引脚，修改L/R设置或时隙映射 |
| 语音有“咔哒”声 | PDM走线过长/电源纹波大 | 缩短PDM走线，在麦克风供电处加RC滤波，检查参考电压退耦电容 |
| 音量偏小 | 应用层采样格式位宽比实际小 | 录音格式改为S32_LE，检查AC108输出位宽寄存器配置 |
| TDM数据错位，两片数据混叠 | 时钟不同步/时隙重叠 | 统一时钟源，配置主从级联，逐片验证时隙内容 |
6.2 一次真实的“爆音”排查经历
有次测试时发现，设备运行十几分钟后，录音会突然出现持续“咔哒”声，重启又正常。一开始我怀疑是DMA丢数据，查了半天dmaengine的配置，结果发现是AC108芯片温度升高后，内部锁相环失锁导致PDM时钟抖动。解决办法居然很简单：把芯片附近的散热铜皮加大，同时在I2S的mclk上加了一颗22Ω电阻抑制过冲，问题就没再出现。
这类问题在文档里很难找到现成答案，更像是一个“经验+毅力”的排查过程。我的体会是：模拟/混合信号芯片的很多诡异现象，优先怀疑电源和时钟，不要一上来就怀疑驱动代码。
6.3 几个少有人提的细节
- PDM麦克风的DATA引脚要避免浮空：不用的数据通道最好通过电阻拉到GND，否则芯片内部可能检测到随机脉冲，导致本应静音的通道出现噪声。
- TDM模式的槽位宽度和采样率有关系：如果采样率提高到96kHz，槽位宽度和BCLK频率要重新算，直接沿用48kHz配置可能导致数据错位。
- 不要忽略主控I2S控制器的FIFO水位：如果DMA中断延迟过大，I2S FIFO会溢出，现象就是每过一段时间就掉几个采样点。这种问题可以通过提高DMA优先级或者调整FIFO阈值来缓解。
7. 应用场景扩展与个人体会
AC108这套方案我实际用下来，感觉最适合的项目类型是：6到8通道以内的麦克风阵列语音产品，尤其是对成本敏感、PCB面积受限的设备。它的上限比较明确——8通道、TDM输出、I2C配置——做不了更高通道数的场合。如果你要上16通道甚至更多，不如直接看带多路TDM输入的DSP或者更高阶的音频采集芯片组。但话说回来，8通道已经能应付绝大多数智能音箱、会议全向麦、车载语音交互的场景了。
我自己的体会是，选这类“小封装、多功能”的芯片，最忌讳只看规格书参数，不看驱动生态和调试便利性。AC108的Linux驱动在社区里很常见，很多主流主控平台的BSP里都直接带了适配，这一点比一些冷门芯片省心太多。遇到问题时，搜索AC108或它的兼容型号，能找到不少现成的解决方案。
最后分享一个我个人的选型习惯：评估任何一颗“类似AC108”的芯片前，先画一张“芯片做了什么，主控做了什么，软件要做什么”的职责划分图。如果芯片能把模拟采集、滤波、串行化都打包好，而且能用标准I2S直接接入主控，这类芯片在集成阶段通常都比较顺利。反之，如果把太多工作丢给主控和驱动开发者，即使芯片本身性能再好，落地成本也会让你怀疑人生。
做麦克风阵列也好，做音频前端也罢，芯片只是整个链路的一部分。真正决定产品体验的，还是你对信号链路的理解深度和对细节的把握程度。希望这篇围绕AC108的拆解和复盘，能帮你少走几步弯路。
本文还有配套的精品资源，点击获取
