在 Android 中使用 OpenSL ES 而不是 AudioTrack 的原因是什么？答案

【问题标题】：What should be reasons to use OpenSL ES instead of AudioTrack in Android?在 Android 中使用 OpenSL ES 而不是 AudioTrack 的原因是什么？
【发布时间】：2012-06-27 03:44:19
【问题描述】：

目前我正在使用 AudioTrack 将来自本机层的音频数据传递给它来播放。

看来我可以在本机层使用 OpenSL ES 而不是 Java 中的 AudioTrack。与 AudioTrack 相比，OpenSL ES 的假定优势是什么？

【问题讨论】：

我猜优势主要来自便携性。假设其他操作系统也支持 OpenSL ES。

标签： android android-ndk audiotrack opensl

【解决方案1】：

虽然这是旧的，但其他人会像我一样通过搜索来到这里。我在一个相当慢且低功耗的平板电脑（Onda V10 4G，联发科处理器）上使用 Android 7，没有其他应用程序处于活动状态。在播放从电视录制的 .ts 文件时，我发现音频通过蓝牙连续丢失，尽管通过平板电脑的扬声器（可能是耳机，尽管我没有测试）很好。音频输出设置为默认 OpenSL ES。我更改为 AudioTrack，现在音频很好，即使对于通过网络访问的文件也是如此。 VLC 当前日期为 2021 年 8 月 1 日。顺便说一句，通过蓝牙，我发现声音和字幕与屏幕上的内容相匹配（没有像我有时发现的那样大的偏移），尽管口型同步并不准确）。我没有尝试补偿延迟，默认保留。

通过 Kodi 可以正常播放文件。

因此，在这种情况下，使用 AudioTrack 是令人信服的理由。可能有一些设置可以让 OpenSL 工作，但我没有打扰。

【讨论】：

【解决方案2】：

OpenSL ES：

优点：

Android 中的低级音频 API
Android 手机上的设备独立
适合游戏

缺点：

仅支持 2.3+ 操作系统

音轨：

优点：

高级 API

缺点：

在Java层工作，Native代码必须调用javalayer才能播放音频。

【讨论】：

谢谢。你是什么意思'设备独立'和'适合游戏'你能详细说明一下或给我一个链接吗？
使用 OpenSL ES，您可以在 Native 库中编写所有内容，并且不需要为音频调用 Java 层，这在游戏中增加了一些性能优势。它比 Android 中的任何其他 API 都更独立于平台。
由于 OpenSL ES 是原生 C API，调用 OpenSL ES 的非 Dalvik 应用程序线程没有 Dalvik 相关的开销，例如垃圾收集暂停。但是，除此之外，使用 OpenSL ES 并没有额外的性能优势。特别是，使用 OpenSL ES 不会导致比平台通常提供的更低的音频延迟、更高的调度优先级等。来自：mobilepearls.com/labs/native-android-api/opensles/index.html