对于实时音频处理,Java是C/ C++的合适替代品吗?
我正在考虑一个应用程序与~100 (在最大)音频轨道与延迟线(30s @48 max),滤波(512点FIR?),和其他DSP类型的操作同时发生在每个轨道上。
这些操作将被转换并以浮点形式执行。
该系统可能是运行Ubuntu的四核3 3GHz内存为4 4GB的系统。
我看过关于Java比以前快得多的文章,接近C/ C++,并且现在也有实时扩展。这是现实吗?是否需要硬核编码和调优才能达到C语言的%50-%100性能?
我真的是在寻找一种感觉,如果这是可能的,并为任何陷阱。
发布于 2009-01-02 18:37:50
对于音频应用程序,您通常只有很少的代码部分,而大部分时间都花在这些部分上。
在Java中,您可以始终使用JNI (Java Native interface),并将计算繁重的代码移到C模块中(如果确实需要的话,也可以使用SSE进行组装)。所以我会说使用Java并让你的代码正常工作。如果结果表明您没有达到性能目标,请使用JNI。
90%的代码很可能是胶水代码和应用程序的东西。但请记住,这样做会失去一些跨平台功能。如果您能忍受这种情况,JNI将始终为您敞开本机代码性能的大门。
发布于 2010-03-06 19:22:21
Java适用于许多音频应用程序。与其他一些帖子相反,我发现Java音频是一个可以使用的joy。将你可用的应用程序接口和资源与可怕的、几乎没有文档记录的CoreAudio进行比较,你就会信以为真。Java音频受到一些延迟问题的困扰,尽管对于许多应用程序来说这是无关紧要的,并且缺乏编解码器。还有很多人从来没有花时间编写好的音频回放引擎(提示,永远不要关闭SourceDataLine,而是给它写零),然后把他们的问题归咎于Java。从应用编程接口的角度来看,Java audio非常简单,非常容易使用,并且在jsresources.org上有很多指导。
发布于 2009-01-02 18:29:05
当然,有何不可?
关键问题(与语言无关,这来自排队论)是:
您需要处理的最大吞吐量是多少(您已经指定了100 x 48 frequency?)
如果您的程序可以跟上平均吞吐量,并且您有足够的延迟空间,那么您应该能够将队列用于输入和输出,并且程序中唯一对计时至关重要的部分是将数据放入输入队列并将其从输出队列中取出并将其发送到DAC/扬声器/其他设备的部分。
延迟线的计算量很小,你只需要足够的内存(+内存带宽)…实际上,您可能只需要使用输入/输出队列,即立即开始将数据放入输入队列,并在30秒后开始从输出队列中取出数据。如果它不在那里,那么你的程序太慢了…)。
FIRs更昂贵,这可能会成为瓶颈(&你想要优化的东西),除非你有其他丑陋的、令人讨厌的操作。
https://stackoverflow.com/questions/407624
复制相似问题