个人理解的音频流程

音频流程

 

场景

  电话，免提，ringtone, 音乐，蓝牙，蓝牙电话，voip, hdmi ,耳机插入

App

 Mediaplayer ,audiorecord.

 

Framework

 很多场景的实现，优先级就在 frameworks/av/services/audiopolicy 去切换的，有很多 profile

 

，如多个声卡的选择，usb ，bt （a2dp） ，primary (主codec ,耳机，有的hdmi 也在里面， 有的 蓝牙 sco ), pcm ，hdmi 都在这里切换。

 

Hardware

主要是 tinyalsa 下的一些配置，不同的代码，如 Usb 的，主codec 的，hdmi 的，蓝牙 a2dp 的。位置可能不一样。

 

主codec 是有很多场景的配置，一般在hardware/rockchip/audio/tinyalsa_hal 里，codec_config 会给出很多配置，

 

rt3224_speaker_incall_controls， rt3224_speaker_ringtone_controls， rt3224_speaker_voip_controls     rt3224_earpiece_incall_controls

 

其实都是针对 alsa 的字符串进行配置的。

 

可控的字符串如下由内核 alsa 生成，比较复杂，但是可以按规则来。

 

一般用 tinyalsa 可以或许到，tinyalsa 有一些命令，如： tinyplay ,tinycap ,tinymix,tinyinfo

 

Tinymix 可以看到很多配置字符串，也可以进行配置。做一些codec 通路的切换。

 

Kernel

 

主要是 codec 的移植，

Codec 移植挺难搞的，框架的移植，具体ALSA 字符串(widget)的配置。

 

如 SOC_SINGLE("OUTPUT Mono Switch", ES8388_DACCONTROL7, 5, 1, 0); 等

 

位置也不在 driver 里面，一般在 kernel/sound/ 里面。

有两个文件，一个是 平台的driver , 平台这边的 dai (数字音频接口)

            一个是 codec 的driver,codec 的 dai

 

在 codec 的driver 中，有两个 probe , 一个是 I2c 的，一个是 codec 的

 

在很早以前，codec 的命令还得注意，不然识别不了

现在命令要好一些了。

 

Driver 和 device 匹配后，可以得到注册成功。注册成功后在 dmesg 里搜索 ALSA 字样，可以看到对应的 声卡注册成功。

 

就算硬件没有，也可以注册成功的。当然可以probe 的时候判断一下 codec 是否能读到。

 

框架搭好后，要轮到看是否能真实的把数据传给codec ..

1. 用tinyplay 等命令播放音乐，用示波器看一看 I2s 上面的数据是否正确，如 mclk 出来没，是24m 还是多少m ，然后看 bclk , 然后再看 左右时钟。
2. 波形正确后，检查 codec 对配置，包括上电是不是对的，寄存器能不能写
3. 最重要的是 两边 dai 的配置是否一致， 如采样率 44.1K ，codec 应该怎么配，是否需要 pll 算时钟等
4. 主从关系，slaver or master .,i2s 的格式，
5. Codec 通路，比如会不会配置到了 speaker ,而硬件只接了 headphone

 

最后音效的调试。

 

另外录音的时候，需要注意的是 mic 的偏置电压。增益，以及重采样。如8k 转16k。增益可以在 config 里面改，也可以直接调试 pcm 数据。

 

Codec 调试的比较多，如 rt5631 ,wm8988 ,rt5640 ,tas5721,max9867