低延迟音频播放：AudioUnit vs AudioQueue vs AudioTrack
内容提要
本文介绍低延迟音频播放方案，对比iOS和Android平台技术。iOS用AudioUnit实现5-10ms延迟，Android用AudioTrack或AAudio达10ms内。核心是绕过系统高级API，使用底层接口、小缓冲区和环形缓冲区。文章提供完整代码示例、延迟诊断工具及常见问题修复方法，帮助开发者选择适合实时通话场景的播放方案。
延伸解读
延迟来源与选型要点
文章指出，系统级播放器（如AVAudioPlayer）因音频队列初始化和预缓冲导致延迟高达85-150ms，不适合实时通话。低延迟的关键在于绕过高级API，直接使用底层接口（如AudioUnit、AudioTrack），并采用小缓冲区（如10-20ms）和环形缓冲区。选型时需根据平台和场景权衡：iOS上AudioUnit延迟最低但复杂度高，AudioQueue更易用但延迟稍高；Android上AAudio（8+）推荐，OpenSL ES延迟极低但复杂度高。
环形缓冲区与线程安全
文中代码展示了环形缓冲区的实现，用于生产者（解码/网络线程）和消费者（音频回调）之间的数据传递。关键设计包括：使用无锁或轻量锁（如os_unfair_lock）避免实时线程中的优先级反转；缓冲区满时覆盖旧数据以优先保证低延迟；回调中避免内存分配和锁操作，防止卡顿。这些细节对实际开发至关重要，可避免音频中断和爆音。
常见问题与调试建议
文章列举了实际开发中的典型问题：AudioUnit回调中锁操作导致卡顿（改用os_unfair_lock）、蓝牙切换导致采样率变化（需动态重建AudioTrack）、回调中内存分配引发超时（预分配缓冲区）、部分设备音量控制失效（手动增益）、低延迟模式不生效（运行时检查performanceMode）。建议开发者利用延迟诊断工具（如kAudioUnitProperty_Latency）和实际测量来验证效果。
Q&A
iOS 上实现低延迟音频播放有哪些方案？各自的延迟和适用场景是什么？
iOS 上主要有 AudioUnit (RemoteIO)、AudioQueue (callback) 和 AVAudioEngine 三种方案。AudioUnit 延迟最低（5-10ms），适合实时通话、VOIP、乐器 App；AudioQueue 延迟中等（20-40ms），适合直播播放、游戏音效；AVAudioEngine 延迟较高（30-50ms），适合一般音视频播放。
Android 上实现低延迟音频播放有哪些方案？各自的延迟和适用场景是什么？
Android 上主要有 AudioTrack (MODE_STREAM)、OpenSL ES 和 AAudio 三种方案。AudioTrack 延迟 10-20ms，适合实时通话、低延迟播放；OpenSL ES 延迟 5-15ms，适合极致低延迟（游戏/乐器）；AAudio 延迟 3-10ms，是新一代低延迟 API，推荐使用。
为什么系统默认的音频播放器（如 AVAudioPlayer）延迟高？
系统默认播放器延迟高是因为它们经过高级 API 封装，包含音频队列初始化（20-40ms）、预缓冲多个 buffer（60-100ms）以及硬件延迟（5-10ms），总计可达 85-150ms，不适合实时通话场景。
实现低延迟音频播放的关键技术有哪些？
关键包括：绕过系统高级 API，直接使用底层音频 API（如 AudioUnit、AudioTrack）；使用小缓冲区（如 10-20ms）和高频率回调；预填充最少的缓冲区（1-2 个）；使用线程安全的环形缓冲区进行数据传递。
在 iOS 的 AudioUnit 播放器中，为什么使用环形缓冲区？它有什么作用？
环形缓冲区用于在生产者（解码/网络线程）和消费者（AudioUnit 回调）之间传递 PCM 数据，实现线程安全的数据交换。它避免了频繁的内存分配和锁竞争，确保音频数据连续、低延迟地播放。
在 Android 的 AudioTrack 播放器中，如何配置低延迟？
通过 AudioAttributes 设置 USAGE_VOICE_COMMUNICATION 和 FLAG_LOW_LATENCY，使用 MODE_STREAM 流式模式，并设置 PERFORMANCE_MODE_LOW_LATENCY（Android 8+）。同时使用较小的 buffer（如 10ms）和独立的写入线程。
AudioUnit 回调中为什么不能使用 NSLock？应该用什么替代？
AudioUnit 回调运行在实时线程，使用 NSLock 可能导致优先级反转和音频卡顿。应使用 os_unfair_lock，它不自旋、不降级，更适合实时线程。
AudioTrack 切换到蓝牙后声音变调怎么办？
蓝牙耳机通常要求 16kHz 采样率，而代码可能写死 48kHz。需要监听 AudioManager.ACTION_SCO_AUDIO_STATE_UPDATED 广播，动态重建 AudioTrack 以匹配蓝牙的采样率。
