简短版本： 我正在开发一个合成器应用程序并使用具有低延迟的Opensl。我在Opensl回调funktion中做了所有的音频计算（我知道我不应该，但我还是做了）。现在计算在我的nexus 4上占用了大约75％的cpu时间，所以下一步是在多个线程中进行所有计算。
我遇到的问题是音频开始断断续续，因为回调线程显然是以高优先级运行而我的新线程没有。如果我使用更多/更大的缓冲区，问题就会消失，但实时也是如此。在新线程上设置更高的优先级似乎不起作用。 那么，是否有可能进行线程低延迟音频或者我必须在回调中做所有工作吗？
我有一个256个样本的缓冲区，大约是5ms，而且应该是thread-scheduler-thingie运行我的calc线程的年龄。
答案 0 :(得分：2)
我认为根本问题在于你的合成引擎的性能。使用Cortex-A8或-A9 CPU可以通过单核实现合适的通道数。你用什么语言实现了它？如果碰巧是Java，我建议将其移植到C ++。
使用多个线程进行合成当然是可能的，但会带来新的问题 - 即每个线程必须在生成的音频混合之前进行同步。
除非您采取异步运行合成线程所带来的额外延迟命中，否则可能的设置是在渲染回调中，您会发出额外的合成线程信号，然后在混合之前等待它们完成他们所有人的音频在一起。
（一个明显的优化是渲染回调运行一些处理本身，因为它已经在CPU上运行，否则什么都不做）。
这就是问题所在。除非您可以确定您的synth渲染线程以实时优先级运行，否则每次渲染回调运行时都可能会进行调度命中，如果阻止回调线程等待合成渲染线程赶上，则可能会触及另一个。
上次我在Android上查看音频时，Bionic缺乏设置实时线程优先级的方法（例如SCHED_FIFO）。在任何情况下，是否允许这是操作系统策略的问题：在桌面Linux系统上，您需要是root用户或已调整适当的ulimit（以root身份） - 我不确定Android是做什么的在这里，但我非常怀疑在此权限下默认情况下下载的应用程序不是。对于mlock()代码及其可能的堆栈需要进入物理内存的其他有用权限也是如此。