用于音频处理的Java实用吗？ java是C++ C/C++实时音频处理的替代方案吗？

我正在考虑一个应用程序，它有大约100（最大）个音轨，带有延迟线（30s@48khz）、滤波（512点FIR？），以及在每个音轨上同时发生的其他DSP类型的操作

这些操作将被转换并以浮点形式执行

该系统可能是一个四核3GHz，4GB内存，运行Ubuntu

<>我看到了一些关于java的文章比以前快得多，接近C++，现在也有实时扩展。这是现实吗？它是否需要硬核编码和调优来实现某些指定的C语言的%50-%100性能

我真的在寻找一种感觉，如果这是可能的，并为任何陷阱做好准备。

当然，为什么不呢

关键问题（与语言无关，这来自排队论）是：

• 您需要处理的最大吞吐量是多少（您指定了100 x 48kHz，是单声道还是立体声，在该频率下有多少位等效？）
• 您的Java例程平均能跟上这个速度吗
• 允许的最大延迟是多少

如果您的程序能够保持平均吞吐量，并且您有足够的延迟空间，那么您应该能够使用队列进行输入和输出，程序中唯一对计时起关键作用的部分是将数据放入输入队列并将其从输出队列中取出并发送给DAC/扬声器/任何东西的片段

延迟线的计算量很低，您只需要足够的内存（+内存带宽）。。。事实上，您可能只需要使用输入/输出队列，即立即开始将数据放入输入队列，30秒后开始从输出队列中取出数据。如果它不在那里，你的程序太慢了

---

Fir更昂贵，这可能会成为瓶颈（以及您想要优化的内容），除非您考虑到其他一些糟糕的操作。

对于音频应用程序，您通常只有非常小的代码部分，大部分时间都花在这些代码上

在Java中，您可以始终使用JNI（Java本机接口）并将计算量大的代码移动到C模块中（如果您确实需要这种能力，可以使用SSE进行汇编）。所以我要说的是使用Java并让代码正常工作。如果您没有达到性能目标，请使用JNI

---

90%的代码很可能是胶水代码和应用程序。但请记住，这样做会丢失一些跨平台功能。如果您能够接受JNI，那么它将始终为您打开本机代码性能的大门

在你的问题中，我没有看到一件事，那就是你是否需要播放这些处理过的样本，或者你是否正在用它们做其他事情（例如，将它们编码到一个文件中）。我更担心Java声音引擎的状态，而不是JVM处理样本的速度

几年前，我在javax.sound.sampled上下了相当大的功夫，但最终还是没能给我留下深刻的印象——它无法与类似的框架（如OpenAL或Mac/iPhone的核心音频）相比（这两个框架的强度我都使用过）。sampled要求您将样本推入一个持续时间未知的不透明缓冲区，这使得同步几乎不可能。它的文档记录也很差（很难找到通过一行传输不确定长度音频的示例，而不是内存片段的小示例），没有实现方法（DataLine.getLevel（）…其非实现甚至没有文档记录），最重要的是，我相信Sun在几年前解雇了最后一位JavaSound工程师

---

如果我有使用Java引擎进行声音混合和输出，我可能会尝试将JOAL绑定到OpenAL作为第一选择，因为我至少知道该引擎目前受到支持，并且能够实现非常低的延迟。尽管我怀疑从长远来看Nils是正确的，最终你会使用JNI来调用本机声音API。

我认为延迟将是你的主要问题-在现代操作系统上，很难在C/C++中保持延迟，java肯定会增加这个问题（垃圾收集器）。“实时”音频处理的一般设计是让处理线程按实时调度运行（linux内核上的SCHED_FIFO，其他操作系统上的等效线程），这些线程永远不会阻塞。这意味着没有系统调用，没有malloc，当然没有IO，等等。。。甚至分页也是一个问题（从磁盘到内存获取一个页面很容易需要几毫秒），所以您应该锁定一些页面，以确保它们永远不会被交换出去

---

您可以用Java做这些事情，但Java使它变得更复杂，而不是更容易。我会研究一种混合设计，核心是C语言，其余的（GUI等）都是java语言，如果你愿意的话。

为什么不花一天时间编写一个简单的java应用程序，进行最少的处理并验证性能是否足够。

查看一个名为Jsyn的库

---

Java适用于许多音频应用程序。与其他一些海报不同，我觉得使用Java音频是一种乐趣。将你可用的API和资源与CoreAudio中可怕的、几乎没有文档记录的mindf*k进行比较，你就会成为一个信徒。Java音频存在一些延迟问题，尽管对于许多应用程序来说，这是不相关的，并且缺少编解码器。还有很多人从未花时间编写好的音频播放引擎（提示，永远不要关闭SourceDataLine，而是向其写入零），然后将问题归咎于Java。从API的角度来看，Java audio非常简单、易于使用，at上有很多指导。

是的，Java非常适合音频应用程序。您可以使用Java并通过Asio访问音频层，并且具有非常低的可用性