基于安卓平台的智能手机芯片回来后要做bringup。首先是负责平台的把安卓OS起来，然后就轮到各功能模块做bringup了，Audio是其中主要功能模块之一。Audio由于场景多和牵涉到的core多，bringup工作会多些。本人曾多次做过智能手机和智能手表上audio 的bringup，主要负责audio DSP上的软件调试。本文就讲讲一款安卓智能手机芯片上audio的bringup。
芯片先是设计，做完硬件相关的验证后去流片，过一段时间后才回来。这是一个相对较长的时间。在这期间软件人员一方面在FPGA上做芯片验证，另一方面在FPGA上做软件功能开发。要求芯片回来前跟硬件无关的软件要ready，跟硬件相关的代码要写好，芯片回来后就开始调试，确保各基本功能OK，可以快速推向市场。所谓bringup就是芯片回来后做软件调试看硬件是否有问题以及软件基本功能完成的过程。对于智能手机来说，audio的基本功能如下：codec播放音乐，codec APP录音，codec电话，蓝牙播放音乐，蓝牙电话，codec VoIP电话，蓝牙 VoIP电话。这些功能调完了，bringup就算结束了。Audio牵涉到AP、ADSP以及CP，做bringup时是各模块相互配合联合调试完成的。
在讲bringup前先看看这款手机芯片跟音频相关的硬件框图，如图1。
图 1
从上图看出，跟音频相关的core有AP、ADSP以及CP，各个core之间通过IPC通信。可以通过codec或者蓝牙采集和播放音频，其中Codec芯片内置，蓝牙芯片（它负责与蓝牙耳机通过蓝牙空口通信）外置。先看看各种基本功能下的audio data path。
1，codec音乐播放
图2是codec播放音乐时的data path。音频流从AP发给ADSP，ADSP做解码以及后处理等，然后把音频数据经过ADMA送给codec播放出来。
图 2
2，codec APP录音
图3是codec APP录音时的data path。从codec采集到音频，经过ADMA送给ADSP，ADSP处理后送给AP，AP将音频数据编码后保存成文件。
图 3
3，codec电话
图4是codec电话时的data path。上行时codec 采集音频数据通过ADMA送给ADSP，ADSP处理后送给CP，CP处理后通过空口送给对方。下行时CP从空口收到对方数据，处理后发给ADSP，ADSP处理后通过ADMA发给codec播放出来。AP主要负责控制流程。
图 4
4，蓝牙播放音乐
图5是蓝牙播放音乐时的data path。音频流从AP发给ADSP，ADSP做解码以及后处理等，然后把音频数据经过UART发给蓝牙芯片， 蓝牙芯片再通过空口发给蓝牙耳机播放出来。
图 5
5，蓝牙电话
图6是蓝牙电话时的data path。上行时蓝牙耳机采集音频数据通过蓝牙空口发给蓝牙芯片，蓝牙芯片通过PCM bus和ADMA把音频数据送给ADSP，ADSP处理后送给CP，CP处理后通过空口送给对方。下行时CP从空口收到对方数据，处理后发给ADSP，ADSP处理后通过ADMA和PCM bus发给c蓝牙芯片，蓝牙芯片通过蓝牙空口把音频数据发给蓝牙耳机播放出来。AP依旧主要负责控制流程。
图 6
6，codec VoIP电话
VoIP电话主要是指APP里的语音通话，比如微信里的微信语音。图7是codec VoIP电话时的data path。上行时codec 采集音频数据通过ADMA送给ADSP，ADSP处理后送给AP。下行时AP把音频数据发给ADSP，ADSP处理后通过ADMA发给codec播放出来。这时AP不仅负责控制流程，同时语音通信的整个方案大部分都是在AP的APP里做的。ADSP主要就是负责音频的采集和播放。
图 7
7，蓝牙VoIP电话
图8是蓝牙VoIP电话时的data path。上行时蓝牙耳机采集音频数据通过蓝牙空口发给蓝牙芯片，蓝牙芯片通过PCM bus 和ADMA把音频数据送给ADSP，ADSP处理后送给AP。下行时AP把音频数据发给ADSP，ADSP处理后通过ADMA和PCM bus把音频数据送给蓝牙芯片，蓝牙芯片再通过蓝牙空口发给蓝牙耳机播放出来。同codec VoIP电话一样，ADSP主要就是负责音频的采集和播放。
图 8
做bringup时有个相对的先后顺序，比如调IPC通常是最先做的，因为它不仅是核间通信，ADSP上的log以及dump音频数据等debug手段也要靠它，可以说是基础设施了，它好了才可以调其他功能。下面就以相对的先后顺序来讲bringup。
1,IPC调试
这里的IPC调试是指AP与ADSP之间的IPC。后面还有ADSP与CP之间的IPC调试，主要用在打电话时，就放在那里调了。AP把ADSP boot起来后ADSP会给AP发个IPC，告诉ADSP已经boot起来了。AP收到IPC中断后能进中断服务程序就说明ADSP给AP的IPC通了。调AP给ADSP的IPC也类似。调试过程中出现问题通常是中断号不对、IPC基地址不对等，相对好查。IPC调好后就可以通过它把ADSP的log发给AP打印出来，要dump音频数据也通过IPC把音频数据发给AP保存成音频文件。之所以这么做是因为ADSP上通常没有打印和dump音频功能。
2，调试audio driver
这里audio driver是指codec的driver，要能播放和录音。这也是audio功能的基础设施。播放和录音好了才可以开发具体的功能。我的习惯是先调播放，把正弦波送给codec，如从扬声器里能听到tone音，就说明播放功能ok。再调录音，把采集到的音频数据通过IPC发给AP保存成文件，然后用工具听，跟自己说的内容一样就说明录音调好了。调试过程中遇到问题需要硬件、ASIC和analog的support，比如某个寄存器的配置是否正确，量某个pin输出的波形是否符合期望，跳线帽有没有跳对等。
3，基本功能调试
基本功能调试时用的都是一些常规的方法，比如log和dump 音频数据等。
codec音乐播放：前面说过在芯片回来前已把在FPGA上能调的功能基本调好，音乐播放就是其中之一。在FPGA上用命令行来做音乐播放，由于没有codec，就把送给codec的音频数据保存成文件来确认结果。不管是WAV格式的还是需要解码的如MP3之类格式的，当时均已调好。当芯片回来后且codec driver已调好时，音乐播放很快调好了。
codec APP录音：同codec音乐播放一样，芯片回来前已在FPGA上用命令行把流程调好。用正弦波来替代codec录到的音频数据，ADSP把正弦波送给AP保存成文件，再去用类似CoolEdit这样的工具去听，是正弦波就算录音流程ok了。当芯片回来后且codec driver已调好时，用真正采集到的音频替代正弦波，APP录音也很快调好了。
codec电话：在芯片回来前ADSP上的语音通路已通过打桩做过调试。上行时用正弦波替代通过codec采集到的音频，把上行处理后发给CP的音频数据（语音编解码在CP上做）dump出来看是否符合期望。下行时把CP发给ADSP的用正弦波替代，把下行处理后送给codec的音频dump出来看是否符合预期。也定义好了ADSP和CP的交互接口，写好了代码等芯片回来后调试。语音通话牵涉到3个core(AP，ADSP，CP)，模块较多，调试参与的人也较多。通常是链路上其他模块先调好，最后跟ADSP联调，调的就是ADSP和CP之间的接口，很快会调好能打电话了。需要说明的是VE（voice enhancement，语音增强，比如回声消除、降噪等）没在这时调，VE要在bringup结束后专门去调试和tuning。
蓝牙音乐播放：这款芯片上BT music为了省播放时的功耗做成了A2DP offload模式。A2DP offload是指把BT host里的A2DP从AP移到ADSP上，这样ADSP就多了A2DP的功能（这功能由BT的同学负责）。这么处理后播放蓝牙音乐时AP就能长时间的睡下去来降功耗。Audio做好SBC编码后把SBC码流送给A2DP，A2DP处理后通过UART送给蓝牙芯片，进而送给蓝牙耳机播放出来。开发时就写好了A2DP向audio要SBC码流的机制，即A2DP的SBC码流buffer空到threshold时向audio要SBC码流，来驱动audio来干活。芯片回来前把能调的都调好了，芯片回来后主要调的就是A2DP和audio的交互机制。要确保从蓝牙耳机里听到的音乐不断续卡顿。经过一番联调后，蓝牙音乐播放基本不断续卡顿了。
蓝牙电话：相对于codec 电话，蓝牙电话主要区别在于声音的采集和播放。蓝牙电话时ADSP从外置的蓝牙芯片处获取采集到的音频数据，也会把音频数据送给蓝牙芯片。ADSP和蓝牙芯片是通过PCM Bus通信的，其driver在芯片回来前就已写好。在调蓝牙电话前要先把相关驱动调好。调试过程中通过示波器看pcm bus的时钟信号以及帧同步信号是否符合预期。Driver调好后再与ADSP上调codec电话时已调好的上下行通路联调，很快就能调好打蓝牙电话了。
VoIP电话：VoIP电话的大部分实现是在AP上，ADSP上仅仅负责音频的采集和播放。ADDP把采集到的音频通过IPC发给AP，同时把从AP收到的音频送给外设播放出来。调试时基于一款有VoIP功能的APP来调，我调试时就在手机EVB板上装上微信然后打微信语音来调。Codec VoIP电话和BT VoIP电话也仅仅是采集和播放不一样，就不再细讲了。这两种VoIP电话也能很快调好。
以上基本功能调完后，bringup就算结束了。
为了更好的跟大家沟通，互帮互助，我建了一个微信讨论群。如您有兴趣，请扫下方的二维码加好友（备注来意），我拉您进群。谢谢！
