Alsa 遇上Android的音频延迟问题
Alsa开始是被Android使用的，后来觉得其复杂，就没有使用了，改用tinyalsa。再后来Android暴露出一个问题，音频相关延迟比较大，iOS可以做到10ms，而Android手机平均还要150ms。Android上实现的OpenSL ES也只是比Java API快一点，并不理想。后来Android添加了FastMixer和AUDIO_OUT_PUT_FLAG_FAST等，来解决这个问题。
在Google给自己的亲儿子优化的比较好，我在Nexus 5上测试使用OpenSL ES可以达到45ms。这个算是比较理想了。Android音频延迟测试方法。
说了一堆别的，说回Alsa，可能过３年后，所有的Android设备都达到像iOS一样10ms，但是目前来讲很多盒子还是达不到的。下游厂家好像没有动力去和Google一样添加FastPath的支持，判断支持不支持，需要用到这两个特性：
android.hardware.audio.low_latency 指示 45 毫秒或更短的持续输出延迟时间。
android.hardware.audio.pro 指示 20 毫秒或更短的持续往返延迟时间。
来源：https://developer.android.com/ndk/guides/audio/audio-latency.html
目前很多设备还不支持这两个特性呢。在目前情况下，要解决延迟问题帮助厂家实现FastPath；要么使用Alsa来代替MediaService。播放有Aplay，混音有dmix。关于dmix有几个不错的文档在嵌入式平台中利用alsa dmix实现混音以及alsa调试成功[转] 。
但是会有一种情况是，有些内核不支持使用dmix这个plugin进行混音，原因是dmix需要内核的声卡驱动支持mmap，但是有些平台的音频驱动并不支持mmap。那么不改内核的情况下只能改用别的混音方式了，别的混音有：PulseAudio，Jack等等。 | 
转播
