第4章开发环境搭建

第4章开发环境搭建：SDK获取与编译、ADB与串口调试工具配置、音频调试工具链、日志系统

好，咱们进入实战环节的第一步——搭环境。

说实话，很多工程师觉得搭环境是体力活，随便搞搞就行。但我见过太多项目，最后卡在环境问题上，一卡就是两三天。MTK8676这套东西，SDK结构复杂，音频调试链路又长，环境没搭好，后面寸步难行。

我个人习惯，先把环境分成四块来搞：SDK获取与编译、ADB与串口调试、音频调试工具链、日志系统。一块一块啃，别急。

4.1 SDK获取与编译

MTK的SDK不像高通那样公开下载。你需要跟MTK的FAE签NDA，拿到专属的Release包。我记得第一次拿到的压缩包叫 MT8676_Android_S_Release_V1.0.tar.gz，解压出来大概30多个G。

拿到之后，第一件事不是编译，而是检查环境依赖。MTK官方推荐Ubuntu 18.04或20.04，我个人建议用20.04，坑少一些。

注意：千万别用Windows WSL来编译MTK的SDK。我曾经试过，编译到一半报错，查了两天才发现是WSL的文件系统大小写敏感问题。老老实实用原生Linux。

编译前需要安装的依赖包，我列个清单：

sudo apt-get install -y git-core gnupg flex bison gperf build-essential \
  zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 \
  lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache \
  libgl1-mesa-dev libxml2-utils xsltproc unzip python3 python3-pip

装完之后，进入SDK根目录，执行：

source build/envsetup.sh
lunch mt8676_car-userdebug
make -j16 2>&1 | tee build.log

这里有个小技巧：tee build.log 会把编译日志同时输出到屏幕和文件。万一编译失败，你可以回头翻日志，不用重新跑一遍。

第一次全编译，我的机器（32核，64G内存）跑了大概45分钟。如果你的机器配置低一些，可能得2-3小时。嗯，这时候可以去喝杯咖啡。

4.2 ADB与串口调试工具配置

编译完，接下来就是跟板子打交道了。

4.2.1 ADB配置

MTK8676的ADB默认是通过USB连接的。但车载场景下，很多板子是通过网口转ADB的。你需要配置 adb connect 模式。

首先，确保板子和PC在同一个网段。然后：

adb connect 192.168.1.100:5555
adb devices

如果显示 unauthorized，别慌。去板子的屏幕上确认一下RSA授权。但车载座舱很多时候没有屏幕，怎么办？

我的做法：在板子的 build.prop 里加上 ro.adb.secure=0，然后重新编译烧录。这样ADB默认就是授权状态，省去弹窗确认的麻烦。

4.2.2 串口配置

串口是最后的保底手段。当ADB连不上、系统卡死的时候，串口是你唯一的救命稻草。

MTK8676的串口通常是UART0，波特率921600。注意，不是115200。我第一次用115200去连，看到一堆乱码，还以为是硬件坏了。

推荐用 minicom 或者 screen：

sudo screen /dev/ttyUSB0 921600

如果你用 minicom，记得先执行 sudo minicom -s 配置串口参数。我个人更习惯 screen，因为它退出方便——按 Ctrl+A 再按 K 就退出了。

4.3 音频调试工具链

音频调试是咱们课程的核心。MTK8676的音频架构，说白了就是三层：Audio HAL、TinyAlsa、DSP固件。

4.3.1 Audio HAL

MTK的Audio HAL在 vendor/mediatek/proprietary/audio/hal/ 目录下。编译后会生成 audio.primary.mt8676.so。

调试HAL层，最常用的方法是加log。我习惯在关键函数入口加 ALOGD：

ALOGD("openInputStream: sample_rate=%d, channel_mask=%d", sample_rate, channel_mask);

然后通过 logcat -s audio_hal_primary 来过滤查看。

4.3.2 TinyAlsa

TinyAlsa是Android底层的音频接口，比ALSA更轻量。MTK8676的音频通路控制，很多都是通过TinyAlsa的 tinymix 命令来做的。

常用的调试命令：

# 查看所有音频控件
tinymix

# 设置麦克风增益
tinymix "Mic1 Volume" 80

# 查看当前音频路由
tinymix "Audio Route" "Playback"

核心思路：调试唤醒和降噪，本质上就是调这些控件的参数。比如麦克风增益调太高，底噪就大；调太低，唤醒率又下降。你需要找到一个平衡点。

4.3.3 音频抓取工具

MTK提供了一个叫 AudioDump 的工具，可以抓取PCM数据。路径一般在 vendor/mediatek/proprietary/audio/tools/。

使用方法：

# 开启音频dump
echo 1 > /sys/class/audio/audio_dump/enable

# 抓取完成后，数据保存在 /data/audio_dump/ 目录下
adb pull /data/audio_dump/ .

抓下来的PCM文件，用Audacity打开，看看波形。如果波形有削顶，说明增益太高了。如果波形几乎看不见，说明增益太低。嗯，这就是最直观的调优依据。

4.4 日志系统

日志是调试的眼睛。MTK8676的日志系统分两块：Logcat 和 Kernel Log。

4.4.1 Logcat

Logcat主要看Android上层和HAL层的日志。我常用的过滤方式：

# 只看音频相关日志
logcat -s audio_hal_primary audio_hw audio_policy

# 带时间戳输出到文件
logcat -v time -f /data/logcat.txt

# 实时过滤唤醒相关
logcat | grep -i "wakeup\|voice\|trigger"

这里有个坑：Logcat的buffer默认只有64KB，如果日志量太大，早期的日志会被覆盖。我建议在板子上执行：

logcat -G 4M   # 把buffer扩大到4MB

4.4.2 Kernel Log

Kernel Log主要看底层驱动和DSP的状态。用 dmesg 或者 cat /proc/kmsg。

音频驱动相关的关键字：

mtk-afe — MTK音频前端驱动
snd_soc — ALSA SoC层
adsp — 音频DSP相关

我常用的命令：

# 实时监控内核日志
dmesg -w | grep -E "mtk-afe|snd_soc|adsp"

# 查看DSP固件加载状态
dmesg | grep "adsp"

注意：如果 dmesg 里出现 adsp firmware load failed，说明DSP固件没烧录或者路径不对。这时候唤醒和降噪功能肯定用不了。别问我怎么知道的——我曾经在这个问题上浪费了一整天。

4.4.3 日志同步技巧

调试唤醒问题时，我习惯同时开三个终端：

终端1：logcat -s voice_trigger 看唤醒事件
终端2：dmesg -w | grep adsp 看DSP状态
终端3：tinymix 实时查看音频控件

这样，当你说「你好，小驰」时，三个终端的信息能帮你快速定位问题出在哪一层。

4.5 环境验证

环境搭好之后，做个快速验证：

# 1. 检查音频设备
cat /proc/asound/cards

# 2. 检查ADB连接
adb devices

# 3. 检查TinyAlsa是否可用
tinymix -D 0

# 4. 检查日志输出
logcat -c && logcat &

如果以上都正常，恭喜你，环境搭好了。接下来我们就可以正式开始调优了。

嗯，我记得第一次搭这个环境的时候，光串口波特率就折腾了半小时。所以我把这些坑都写在上面了，你照着做，应该半小时内能搞定。

📚 课程目录