不要嫌前进的慢,只要一直在前进就好
文章目录
- 前言
- 一、系统架构图
- 1.MCU控制音量的架构图(老方法)
- 2.ARM控制音量的架构图(新方法)
- 二、为啥控制音量不是用AudioManager而是执着去直接控制TDA7729?
- 三、MCU控制音量和ARM控制音量各自的优缺点
- 1.MCU控制音量
- 2.ARM控制音量
- 总结
前言
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
学海无涯苦作舟!