在实时音频处理方面，Java 是 C/C++ 的合适替代品吗？
我正在考虑一个应用程序，其中包含约 100 个（最多）音频轨道，延迟线（30 秒 @ 48khz）、过滤（512 点 FIR？）和其他 DSP 类型的操作同时发生在每个轨道上。
这些操作将被转换并以浮点数执行。
该系统可能是一个四核 3GHz 和 4GB RAM，运行 Ubuntu。
我看到有关 Java 比以前快得多、接近 C/C++ 并且现在还具有实时扩展的文章。这是现实吗？是否需要硬核编码和调优才能达到某些 C 语言规范的 %50-%100 性能？
如果这是可能的，我真的在寻找一种感觉，并为任何问题提个醒。
【问题讨论】：
标签： java performance audio signal-processing real-time
对于音频应用程序，您通常只需要花费大部分时间的代码的一小部分。
在 Java 中，您始终可以使用 JNI（Java Native 接口）并将计算量大的代码移动到 C 模块（如果您确实需要强大的功能，也可以使用 SSE 进行程序集）。所以我会说使用 Java 并让你的代码工作。如果事实证明您没有达到性能目标，请使用 JNI。
90% 的代码很可能是胶水代码和应用程序的东西。但请记住，您会以这种方式失去一些跨平台功能。如果您可以接受该 JNI 将始终为您打开本地代码性能的大门。
【讨论】：
Java 适用于许多音频应用程序。与其他一些海报相反，我发现使用 Java 音频是一种乐趣。将您可用的 API 和资源与 CoreAudio 的可怕的、几乎没有文档记录的 mindf*k 进行比较，您就会相信。 Java 音频存在一些延迟问题，尽管对于许多应用程序来说这无关紧要，并且缺乏编解码器。还有很多人从来没有费心花时间编写好的音频播放引擎（提示，永远不要关闭 SourceDataLine，而是向其写入零），然后将问题归咎于 Java。从 API 的角度来看，Java 音频非常简单明了，非常易于使用，jsresources.org 有很多指导。
【讨论】：
当然，为什么不呢？
关键问题（独立于语言，来自排队论）是：
如果您的程序可以跟上平均吞吐量，并且您有足够的延迟空间，那么您应该能够使用队列进行输入和输出，并且程序中唯一对时间至关重要的部分是将数据放入输入队列并将其从输出队列中取出并将其发送到 DAC/扬声器/任何东西的部分。
延迟线的计算负载低，你只需要足够的内存（+内存带宽）......事实上你应该只使用输入/输出队列，即立即开始将数据放入输入队列，然后开始30 秒后从输出队列中取出数据。如果它不存在，那么您的程序太慢了...）。
FIR 更昂贵，这可能会成为瓶颈（以及您想要优化的内容），除非您有其他丑陋的讨厌操作。
【讨论】：
我认为延迟将是您的主要问题 - 在现代操作系统上的 C/C++ 中已经很难维持延迟，而 Java 肯定会增加问题（垃圾收集器）。 “实时”音频处理的一般设计是让您的处理线程在实时调度中运行（Linux 内核上的 SCHED_FIFO，在其他操作系统上等效），并且这些线程永远不应该阻塞。这意味着没有系统调用，没有 malloc，当然没有 IO，等等......甚至分页也是一个问题（从磁盘获取一个页面到内存很容易需要几个毫秒），所以你应该锁定一些页面以确保它们永远不会换掉了。
你也许可以用 Java 做这些事情，但是 java 使它变得更复杂，而不是更容易。我会研究一种混合设计，其中核心将在 C 中，其余部分（GUI 等）将在 java 中，如果你愿意的话。
【讨论】：
我在您的问题中没有看到的一件事是您是否需要播放这些处理过的样本，或者您是否正在对它们做其他事情（例如，将它们编码到一个文件中）。我更担心 Java 声音引擎的状态，而不是 JVM 处理样本的速度。
几年前我对 javax.sound.sampled 进行了相当大的推动，但最终没有留下深刻的印象——它无法与 OpenAL 或 Mac/iPhone 的 Core Audio 等等效框架（我曾在类似的强度水平）。 javax.sound.sampled 要求您将样本推送到持续时间未知的不透明缓冲区中，这使得同步几乎不可能。它的文档也很差（很难找到通过 Line 流式传输不确定长度音频的示例，而不是内存中剪辑的琐碎示例），具有未实现的方法（DataLine.getLevel() ...甚至没有记录），最重要的是，我相信 Sun 在几年前解雇了最后一位 JavaSound 工程师。
如果我不得不使用 Java 引擎进行混音和输出，我可能会尝试使用 JOAL 绑定到 OpenAL 作为首选，因为我至少知道引擎目前得到支持并且能够实现非常低的延迟。虽然我怀疑从长远来看 Nils 是正确的，但您最终会使用 JNI 来调用本机声音 API。
【讨论】：
是的，Java 非常适合音频应用程序。您可以使用 Java 并通过 Asio 访问音频层，并且在 Windows 平台上具有非常低的延迟（64 个样本延迟几乎没有）。这意味着您将在视频/电影上进行口型同步。 Mac 上的延迟时间更长，因为没有 Asio 可以“捷径”将 OS X 和“Java 在顶部”的组合，但仍然可以。 Linux也有，不过我比较无知。有关 Java 和 Asio 完美协调工作的实用（也是世界首创）示例，请参阅 soundpimp.com。另请参阅包含 sw mp3 解码器（来自 Java）的 NRK Radio&tv Android 应用程序。您可以使用 Java 完成大多数音频操作，然后在时间紧迫的情况下使用本机层。
【讨论】：
查看一个名为 Jsyn 的库。
【讨论】：
为什么不花一天时间编写一个简单的 Java 应用程序，该应用程序执行最少的处理并验证性能是否足够。
【讨论】：
来自http://www.jsresources.org/faq_performance.html#java_slow
让我们收集一些以太智慧：
地球是平的。
还有，别忘了：Java 很慢。
正如几个应用程序所证明的（参见链接部分），Java 就足够了 构建音频编辑器、多轨录音系统和 MIDI 处理软件。试试看！
【讨论】：