Android车载MCU控制音量和ARM控制音量的区别和优缺点—TEF6686 FM/AM芯片

不要嫌前进的慢，只要一直在前进就好

---

前言

Android车载系统开发定制晚于Android手机，但是也有10多年的时间，到8.0版本Android专门为车载添加AAOS（CarOS）分支。多年的从业经验也见证了行业的各种技术更新变化，这篇博客讲讲我个人理解的MCU控制音量和ARM控制音量的区别和优缺点。

---

一、系统架构图

1.MCU控制音量的架构图（老方法）

芯驰x9系列平台（Android 10）芯片其实是比较新的一个芯片平台，因为我司客户目标是商用车追求低成本，所以没有完全使用芯驰推荐的那套外设芯片。例如芯驰推荐的DSP是AK7738AVQ，我司用的是TDA7729。7729安卓端芯驰没有封装控制接口，我司MCU有控制7729的工作经验，故音量、音效、通道都是MCU端控制的。

音量和音效很好理解，通道没做过老式车载和车载的就很难理解，我尽量简单的把通道讲清楚。

通道：上图可以看到ARM（数字信号）和TEF6686（模拟信号）都是直连TDA7729输出声音信号，7729默认有多路声音通道，ARM默认通道0，TEF6686使用通道1。参照安卓音频交互矩阵，FM/AM和媒体（本地音乐/视频，酷狗，喜马拉雅等）相互属于独占的音频类型。
例如ARM端当前播放酷狗音乐（通道0）这时用户点想播放FM/AM，那么就需要点击Radio图标并切换到通道1才会有无线电台声音，听一会用户又点击了U盘音乐图标这时又需要切换到通道0才会有ARM端媒体声音。

我入行的时候就是用的这套MCU切通道、控制音量、音效的方法，我称之为“老方法”。

2.ARM控制音量的架构图（新方法）

杰发ATC8257平台（Android 9）也算是比较新的一个平台，平台的优点就是成本低，缺点也有此处不表。
这套方案杰发推荐使用TDA7729，Android端杰发也封装了java控制7729的音量、音效、增益等接口，所以项目启动的时候决定音量的控制放到ARM端。

这就有个TEF6686的音频怎样输出的新问题，杰发给的方案如上图，在ARM创建一个音频节点供6686数字音频输入（对应创建一个录音类型MediaRecorder.AudioSource.FM_CUSTOM），Android端使用AudioRecord + AudioTrack边录边播，我是参照vendor/mediatek/proprietary/packages/apps/FMRadio/这个工程完成的。

这样实现后在ARM端Radio APP跟U盘音乐、酷狗一样的是个媒体类型的APP，使用AudioManager.STREAM_MUSIC音频类型抢音频焦点播放。

从18年AAOS出来后基本都是这种ARM控制系统音量、音效的方法，我称之为“新方法”。

贴一点我当时实现数字FM/AM用的方法：
用命令可以查看pcm设备列表，杰发给的录音节点06，capture/playback 只有PCM设备才有这部分，只有c和p两种。c代表capture，说明这是一个提供录音的设备，p代表palyback，说明这是一个提供播放的设备。
1、查看当前的声卡：cat /proc/asound/cards
2、查看pcm设备列表：cat /proc/asound/pcm
3、查看当前有哪些进程占用了pcm设备节点：lsof |grep pcm
4、查看有哪些音频设备节点：ls /dev/snd/

Android端通过tinycap命令录制这个节点测试是否可用，tinyplay、tinymix、tinycap的使用可以先看下面这篇博客
如何查看声卡、pcm设备以及tinyplay、tinymix、tinycap的使用
用下面命令录制节点6，可录.pcm或者.wav的音频资源，录好pull出来用电脑或者发到手机微信播放，如果节点正常你可以听到6686里面FM/AM的声音。
控制搜台那些我司目前还是通过串口服务发命令给MCU来控制，后续开发ATC8025平台是打算把控制的部分也迁移到ARM端。

adb root
adb shell tinycap /data/test.pcm -D 0 -d 6 -b 16 -r 48000 -c 2
adb shell tinycap /data/radio.wav -D 0 -d 8 -b 16 -r 48000 -c 2
tinycap /data/radio.wav -D 0 -d 4 -b 16 -r 48000 -c 2
adb pull /data/test.pcm 

-D 哪个声卡的意思, 比如usb声卡, 本机mic …
-d 当前声卡下的哪个设备录音, 一般一个声卡下会有多个设备
-c 录音通道数
-b 采样精度,一般是16bit,但是如果需要标记位就要升高精度，如24bit或32bit
-r 录音采样率
-p period size:每个中断周期需要准备的音频空间大小
-n 有多少组 period size

二、为啥控制音量不是用AudioManager而是执着去直接控制TDA7729？

1.能问出这种问题的小伙伴说明你的水平已经是个小高手，起码也是玩过Android多媒体、音量控制的工程师。我曾经也这么灵魂拷问过我的技术领导，他当时给我一个白眼，说车载就是这么做的，现在想想他还是想有所保留的。我一度反复思索多年不得要领，后面在另一家公司我又又灵魂拷问我的副总，这个副总是硬件出身，他说你不直接控制7729音量指标过不了，虽然你在Android把音量调到0但是音频芯片7729有底噪，到这时我才恍然大悟。

2.再结合Android在8.0的时候给车载开的分叉AAOS里面控制音量是CarAudioManager，CarAudioManager有耐心的小伙伴可以追踪一下代码，它也是直接控制的DSP音频芯片音量，也就是跟我前面讲的两种控制音量的方法一样的控制硬件音量，到这里突然就像打通了任督二脉懂了整个车载音频架构设计的逻辑。

3.AudioManager控制的是软件音量，我们称之为软音量；控制7729音量和AAOS的CarAudioManager控制音量都是控制硬件音量，我们称之为硬音量。

4.Android车载一定控制硬音量，不然底噪太大过不了指标。

三、MCU控制音量和ARM控制音量各自的优缺点

1.MCU控制音量

优点：从我Android软件开发工程师角度来说毫无优点，唯一的优点就是搞出产品能卖钱
缺点：APP需要通过串口服务来控制MCU从而达到控制音量，还需要通知MCU当前ARM的媒体播放状态，比较繁琐，出了问题不能快速debug

2.ARM控制音量

优点：ARM控制音量少了跟MCU交互那一层，代码逻辑更清晰明了，有问题可快速debug快速解决
缺点：无，在车载行业目前来看是无缺点，完美

总结

Android车载音频设计是最复杂、最难做、最重要的一部分，把音频部分做好这个系统基本上大差不差可以说做好了。
小伙伴们如果向往这方面发展可以先从多媒体入手，懂了多媒体模块就能懂：音频流、音频焦点，进而可以学习音量管理、音频矩阵、车载音频配置、音频控制hal、多区音频路由等等。

AAOS音频设计的部分每个版本之间也有变化，具体的可以去开源网站上学习
https://source.android.google.cn/docs/automotive?hl=zh-cn

学海无涯苦作舟！