用于音频处理的Java是否实用？

Java是用于实时音频处理的C/C++的合适替代品吗？

我正在考虑一个带有~100(最大)音频轨道的应用程序,延迟线(30s @ 48khz),滤波(512点FIR？),以及同时在每个轨道上发生的其他DSP类型操作.

操作将以浮点转换和执行.

该系统可能是一个四核3GHz,4GB RAM,运行Ubuntu.

我看过有关Java的文章比过去快得多,接近C/C++,现在也有实时扩展.这是现实吗？它是否需要硬核编码和调整来实现C的%50-%100性能指标？

我真的在寻找一种感觉,如果这是可能的,并找到任何陷阱.

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

在Java中,您始终可以使用JNI(Java Native接口)并将计算繁重的代码移动到C模块(如果您真的需要电源,则使用SSE进行组装).所以我会说使用Java并让你的代码正常工作.如果事实证明您不符合您的性能目标,请使用JNI.

无论如何,90%的代码很可能是胶水代码和应用程​​序.但请记住,您通过这种方式放弃了一些跨平台功能.如果您能忍受JNI将永远为您打开本机代码性能的大门.

Java适用于许多音频应用程序.与其他一些海报相反,我觉得Java音频很有用.将您可用的API和资源与CoreAudio中可怕的,几乎没有记录的mindf*k进行比较,您将成为一名信徒.Java音频存在一些延迟问题,但对于许多应用程序而言,这是无关紧要的,并且缺乏编解码器.还有很多人从不打算花时间写出好的音频播放引擎(提示,永远不要关闭SourceDataLine,而是写零),然后责怪Java的问题.从API的角度来看,Java音频非常直观,易于使用,并且在jsresources.org上有很多很多指导.

当然,为什么不呢？

关键问题(独立于语言,这来自排队理论)是:

您需要处理的最大吞吐量是多少(您指定的是100 x 48kHz,是单声道还是立体声,在该频率下等效多少位？)

您的Java例程可以平均跟上这个速率吗？

什么是最大允许延迟？

如果您的程序平均可以跟上吞吐量,并且您有足够的延迟空间,那么您应该能够使用队列进行输入和输出,并且程序中唯一对时序至关重要的部分就是将数据放入输入队列并将其从输出队列中取出并将其发送到DAC /扬声器/其他任何内容.

延迟线具有较低的计算负荷,你只需要足够的内存(+内存带宽)......实际上你应该只使用它的输入/输出队列,即开始立即将数据放入输入队列,并开始取出数据稍后输出队列30s.如果它不存在,你的程序太慢......).

FIR更昂贵,可能会成为瓶颈(以及你想要优化的东西),除非你有其他丑陋的讨厌操作.