OpenSL ES与AAudio简单介绍

原因

在耳返功能时，如果使用AudioRecord和AudioTrack进行采集与播放会造成延迟问题，故需要涉及到openSL ES与AAudio的使用。

概况

OpenSL ES与AAudio简单理解为嵌入式跨平台免费的音频处理库，具有高性能，低延迟的特性。AAudio是作为OpenSL ES库的轻量级原生Android替代项。AAudio性能与功能上更佳。但是AAudio只有在Android 8.0之后才会引入，而OpenSL ES则在2.3之后就已引入。

有关音频的延迟可以简单分为如下几个情况

音频延迟是指音频信号在系统中传输所需要的时间:

音频输出延迟：

是指音频样本由应用生成到通过耳机插孔或内置扬声器播放之间经历的时间。

音频输入延迟：

是指设备音频输入（如麦克风）接收音频信号到这些音频数据可供应用使用所经历的时间。

往返延迟：

是指输入延迟，应用处理时间和输出延迟的总和。

轻触延迟：

是指用户轻触屏幕与轻触事件被应用接收到所有经历的时间。

预热时间：

是指数据第一次在缓冲区加入队列后到启动音频管道所需要的时间。

以上就是各个环节中可能会存在的延迟时间。

针对以上减少延迟时间如下：

减少输入延迟：

从音频路径中移除任何不需要的信号处理操作，避免重采样，设置缓冲区大小。

减少输出延迟：

提供与设备的最佳采样率和缓冲区大小匹配的音频数据。

减少预热延迟：

提前将静音数据缓冲区加入队列。

AAudio：

是在Android O（android 8.0）版本中引入的全新Android C API。该API中不包括音频设备枚举，解码等部分功能。支持的样本格式为PCM_16和PCM_FLOAT，而且内部还具有独立的样本转换模块。

OpenSL ES（Open Sound Library for Embedded Systems）

无授权费，跨平台，针对嵌入式系统精心优化的硬件音频加速API。Android2.3即开始支持OpenSL ES标准，但是不同的版本支持的方法也不同，故涉及到一些兼容性问题。该模块中不支持音频编解码，支持的样本格式为PCM_16，其他格式不能保证兼容所有平台。

以上两种模块的优势：

1：避免音频数据频繁在natvie层与java层拷贝，提高效率。

2：相比如JAVA api更灵活控制参数。

以上两个模块都可以在NDK安装路径下的platforms文件夹下对应平台中找到对应.so。

针对以上两种模块的调用封装在google提供的Oboe模块中。github.com/google/oboe

总结：以上就是简单的针对AAudio于OpenSL ES的简单介绍，具体使用和细节后续补充。

原文链接：blog.csdn.net/u013692429/…

Webrtc与OBOE

To view this discussion on the web visit groups.google.com/d/msgid/dis….

收件人 discuss...@googlegroups.com

If you need C++ support, you should implement [Oboe support](https://stackoverflow.com/a/53124528) since it calls AAudio on newer devices and OpenSL ES on older devices. The Oboe API is a direct mapping of the C AAudio interface into C++ and you need a new ADM to support it in WebRTC. We have no plans on implementing it currently.

Don't use Open SL ES directly on all devices.

My experience is that you don't really need any native interface unless C++ is required.

Java AudioTrack has been improved over the years and can achieve almost the same performance in terms of latency as the native APIs but it also has many other benefits for VoIP applications.

You will not get the lowest latency audio path with WebRTC anyhow since we use built-in effects and that puts you off the fast track.

Android Low delay

延迟问题的概述，请参阅

https://source.android.com/devices/audio/latency.html

为了降低延迟，需要以下方面共同努力：

应用程序开发人员
Android框架
原始设备制造商
SoC供应商（包括音频HAL），
内核
以及测试

应用程序：

source.android.com/devices/aud…

使用基于OpenSL ES的Android原生音频。
使用推荐的本地缓冲区大小和采样率；看见developer.android.com/reference/a…
同样的缓冲区大小和采样率也应用于输入通常，OpenSL ES缓冲区计数为1就足够了。保持回调处理程序的简短，而不会突然占用CPU，并且没有无边界的阻塞，避免优先级倒置。 source.android.com/devices/aud…
使用非阻塞库，以在输入和输出回调处理程序之间进行通信。source.android.com/devices/aud…

框架：

Google一直在不断改进框架。

source.android.com/devices/aud…

文章需要更新以描述最近的改进（尤其是在输入侧）。较新版本可以提供比同一设备上的旧版本更低的延迟。在未来继续做出更多改进，但给不出时间表。

OEM和SoC供应商，包括音频HAL：

在HAL中通常2个缓冲区就足够了。

避免HAL中的优先级倒置，特别注意互斥锁。

避免或减少HAL中的额外音频处理，例如信号“增强”，对低延迟有负面影响的情形。

如果应用程序处理器后有DSP，请保持DSP最小化处理。

不对音频框架进行框架上的更改。

内核：

减少最坏情况下的中断禁用和抢占禁用时间。
电源管理有时会干扰调度。
检查您的DRM安全内核是否有长时间的黑暗时间
在此期间，常规内核无法运行。

使用的测试技术和工具的链接：

https://source.android.com/devices/audio/latency_measure.html
https://source.android.com/devices/audio/loopback.html
https://source.android.com/devices/audio/testing_circuit.html

Android Audio Delay Main cause

根本原因在于ALSA和AudioFlinger 的通信方式。具体来说，AudioFlinger 将音频缓冲区“推送”到 ALSA。“推送”会导致调度问题，从而导致音频质量问题。该机制下媒体服务器或用户应用程序将下一个缓冲区推送给音频驱动程序，无论设备其是否准备就绪。传入音频或可用输出缓冲区时，AudioFlinger与ALSA缓冲区事件并不一定正处在真正连接的状态。

所有专业音频、低延迟系统都使用拉动机制，如，Mac OSX。使用“pull”机制，“按照音频设备的节奏”处理音频。同时，pull机制降低了事件丢失的风险。音频延迟上更低。