10、OpenSL ES低延时配置：SL_ANDROID_KEY_PERFORMANCE_MODE、BufferQueue与回调、与AAudio的对比

聊到Android音频低延时，OpenSL ES是个绕不开的话题。虽然它年纪不小了，API设计也谈不上优雅，但在AAudio普及之前，它几乎是唯一能触及底层音频路径的C++接口。我个人习惯把OpenSL ES比作一把“瑞士军刀”——功能齐全，但用起来需要点耐心。

这一章，我们聚焦三个核心点：性能模式、BufferQueue回调机制，以及它和AAudio的对比。搞懂了这些，你写出来的音频应用延时才能压到最低。

10.1 SL_ANDROID_KEY_PERFORMANCE_MODE：性能模式的正确打开方式

很多新手用OpenSL ES，上来就创建引擎、混音器、播放器，然后发现延时高得离谱。为什么？因为默认配置下，系统会优先保证功耗和稳定性，而不是低延时。

这时候就需要 SL_ANDROID_KEY_PERFORMANCE_MODE 出场了。它是一个扩展接口，用来告诉音频系统：“我要低延时，别给我搞那些花里胡哨的缓冲。”

// 创建引擎时配置性能模式
SLresult result;
SLObjectItf engineObject;
SLEngineItf engineEngine;

// 1. 配置性能模式为低延时
SLint32 performanceMode = SL_ANDROID_PERFORMANCE_LATENCY;
SLboolean enable = SL_BOOLEAN_TRUE;

const SLInterfaceID ids[] = {SL_IID_ANDROIDCONFIGURATION};
const SLboolean req[] = {SL_BOOLEAN_TRUE};

result = slCreateEngine(&engineObject, 0, NULL, 1, ids, req);
// 检查result...

// 2. 获取配置接口
SLAndroidConfigurationItf configItf;
result = (*engineObject)->GetInterface(engineObject, 
    SL_IID_ANDROIDCONFIGURATION, &configItf);

// 3. 设置性能模式
result = (*configItf)->SetConfiguration(configItf, 
    SL_ANDROID_KEY_PERFORMANCE_MODE, 
    &performanceMode, sizeof(SLint32));

// 4. 然后才初始化引擎
result = (*engineObject)->Realize(engineObject, SL_BOOLEAN_FALSE);

这里有个坑，我曾经踩过：性能模式必须在引擎Realize之前设置。一旦引擎初始化完成，再改就晚了。系统会直接忽略你的配置。

另外，不是所有设备都支持这个模式。我建议你在初始化后检查一下返回值。如果返回 SL_RESULT_FEATURE_UNSUPPORTED，说明设备不支持，那就只能退而求其次了。

10.2 BufferQueue与回调：掌控数据流动

配置好性能模式只是第一步。真正决定延时的是你如何处理音频数据。OpenSL ES提供了两种方式：简单缓冲队列（Simple Buffer Queue）和回调（Callback）。

简单缓冲队列，说白了就是你自己管理一个环形缓冲区，不断往里面填数据。系统会按固定节奏来取。这种方式灵活，但容易出错。

回调方式更优雅——系统会在需要数据时主动调用你的函数。我个人更推荐回调，因为它能让你精确控制每次处理的数据量。

// 假设你已经有了播放器对象 playerObject
SLPlayItf playerPlay;
SLBufferQueueItf playerBufferQueue;

// 获取BufferQueue接口
result = (*playerObject)->GetInterface(playerObject, 
    SL_IID_BUFFERQUEUE, &playerBufferQueue);

// 注册回调函数
result = (*playerBufferQueue)->RegisterCallback(playerBufferQueue, 
    BufferQueueCallback, this);

// 回调函数实现
void BufferQueueCallback(SLBufferQueueItf caller, void *context) {
    MyApp* app = (MyApp*)context;
    
    // 获取当前队列状态
    SLBufferQueueState state;
    (*caller)->GetState(caller, &state);
    
    // 如果队列中还有缓冲，就不处理
    if (state.count >= app->bufferCount - 1) {
        return;
    }
    
    // 填充下一个缓冲
    app->FillNextBuffer();
    
    // 入队
    (*caller)->Enqueue(caller, app->buffer, app->bufferSize);
}

嗯，这里要注意：回调是在音频线程中执行的，绝对不能做任何阻塞操作。我曾经见过有人在回调里加锁、做日志、甚至分配内存，结果音频直接卡成狗。

关于缓冲数量，我建议用2到3个。太少容易欠载，太多会增加延时。我自己一般用3个，这样即使偶尔调度延迟，也不至于断流。

10.3 OpenSL ES vs AAudio：谁更适合低延时？

AAudio是Google在Android O引入的新音频API，专门为低延时设计。很多人问我：“既然有了AAudio，OpenSL ES是不是该淘汰了？”

我的回答是：看情况。

咱们来做个对比：

特性	OpenSL ES	AAudio
API 风格	C语言风格，回调+队列	C++风格，面向对象
最低延时	5-10ms（取决于设备）	3-5ms（优化后）
兼容性	Android 2.3+	Android O+（8.0）
独占模式	不支持	支持（AAUDIO_PERFORMANCE_MODE_LOW_LATENCY）
XRun处理	需要手动处理	内置回调机制
多线程安全	一般	较好（无锁设计）

从延时上看，AAudio确实更胜一筹。它可以直接访问音频硬件，绕过中间层。但OpenSL ES的优势在于兼容性——如果你的应用需要支持Android 7.0及以下设备，那只能选OpenSL ES。

我个人建议：新项目优先用AAudio，除非你有兼容性需求。如果必须用OpenSL ES，那就按我们前面说的，配置好性能模式，用回调方式，缓冲数量控制在2-3个。

10.4 知识体系图：低延时配置全景

下面这张图总结了OpenSL ES低延时配置的核心路径，以及它与AAudio的关系。你可以把它当作一个快速参考。

这张图把整个流程串起来了。你从顶部开始，先决定用OpenSL ES还是AAudio。如果选OpenSL ES，就按性能模式→BufferQueue→回调这条路径走。每一步都有注意事项，别跳步。