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

Jef*_*ffV 20 java audio performance signal-processing real-time

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

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

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

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

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

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

Nil*_*nck 19

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

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

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


小智 9

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


Jas*_*n S 5

当然,为什么不呢?

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

  • 您需要处理的最大吞吐量是多少(您指定的是100 x 48kHz,是单声道还是立体声,在该频率下等效多少位?)
  • 您的Java例程可以平均跟上这个速率吗?
  • 什么是最大允许延迟?

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

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

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


Dav*_*eau 5

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

您也许可以用 Java 做这些事情,但是 Java 让它变得更复杂,而不是更容易。我会研究混合设计,其中核心将采用 C 语言,其余部分(GUI 等)将采用 Java(如果您愿意)。