OpenSL ES
从Android 2.3（Gingerbread）开始的设备支持OpenSL。然而，从Android 4.2（或4.3？）开始，用于OpenSL（高性能音频）的快速混合器可用，并且并不是所有设备本地支持的。
这是什么意思？基于我的观察，当不使用快速混合器时，Java AudioTrack 比OpenSL 更快（具有较低的延迟）。
当使用快速混频器时，音频延迟实际上是好的和低的。为了实现这一点，您的设备必须支持快速混音器，并且配置参数应该匹配。
另一个需要考虑的问题是GearVR上的“哗然”，可能是由于线程优先级的改变。
要使用OpenSL实现您的音频，您可能需要参考NDK样本，甚至更好的在这里https://github.com/Over17/AndroidAudioFastPathSample - 实际使用快速路径是固定的。
A音频
将在Android O上得到支持，这将在今年的一些时间发布。除非你不希望你的游戏与Android O兼容，否则你可能不想这样做。
我没有太多的手经验。
动机
为什么你真的想要一个本地音频部分的游戏？如果它不是一个合成器，一个专业的音频应用程序或一个VR游戏，我真的不会打扰原生的C ++音频，并去JavaAudioTrack。它是可靠的，与所有设备兼容，并且对于非专业应用程序具有可接受的延迟。
Google昨天宣布Android O，并在Android O中存在新的专业音频流API。我们还没有看到这个新API的响应程度如何，但令人鼓舞的是Google了解到Android中的实时，低延迟音频。这仍然是iOS设备的真正优势之一。我不太确定Google如何处理Android中所有内容的所有Binder延迟，但我很高兴他们将其作为优先事项。
我完全同意，像iOS这样的场景还有几年的时间。这肯定是一个鸡蛋的东西。至少，操作系统将不再妨碍。随着真正的低延迟音频终于可能，越来越多的专业产品将会朝向Android，因为Android用户群体庞大，意味着钱。这样会反过来又会吸引更多的严肃音乐家，而这一切将会回归。这会很慢一段时间，但我怀疑专业人士一直在等待这一点。他们可能会让事情变得比我们预期的更快。到目前为止，他们做的没有关系。大多数Android设备的音频延迟是可怕的，因此会使他们的产品看起来不好，所以他们根本没有开发它们。随着O，这种变化。
事实上，如果Google的家伙从一开始就把低延迟的音频作为一个优先事项，那肯定会影响整个操作系统的设计。Android最初并没有真正实时设计。Google花了很长时间才摆脱了他们在建筑上画的角落，只需要通过Binder长途旅行。
用于Pro Audio的AAudio API：AAudio是一种新的本机API，专为需要高性能，低延迟音频的应用而设计。
对于我来说，听起来似乎太奇怪了，这不仅仅是Android，而且在游戏机上（吉他英雄，摇滚乐队等），它们使得它们完全无法作为乐器摆放 - 我在这里主要考虑一下鼓手。
是的，iPhone是更好的比Android，但它仍然是行不通的作为工具。
OTOH全电子数字乐器已经成为数十年的主流。是因为我们以某种方式能够在游戏中接受可怕的视觉延迟（最近由于网络延迟而加剧）？因此，我们的系统会以延迟为代价优化吞吐量性能（分辨率，fps等）？虽然延迟问题在VR中再次出现丑陋的头。看起来需要10-15毫秒，端到端（从人类输入到输出），用于VR视觉和音频。
无论如何，我认为更好的音频延迟需要对整个系统进行重新设计，而且还不清楚这个新的API是否支持它。