Java は、リアルタイム オーディオ処理のための C / C++ の適切な代替手段ですか?
遅延線 (30 秒 @ 48khz)、フィルタリング (512 ポイント FIR?)、および各トラックで同時に発生するその他の DSP タイプの操作を使用して、最大 100 (最大) のオーディオトラックを持つアプリを検討しています。
演算は浮動小数点に変換されて実行されます。
システムはおそらく 4GB RAM のクアッドコア 3GHz で、Ubuntu を実行しています。
Java が以前よりもはるかに高速になり、C / C++ に近づき、現在はリアルタイム拡張機能も備えているという記事を見てきました。これは現実ですか？C の %50-%100 パフォーマンスを達成するためにハードコアコーディングとチューニングが必要ですか?
これが可能かどうか、そして何か問題がある場合に備えて、私は本当に意味を探しています。
オーディオ アプリケーションの場合、多くの場合、ほとんどの時間が費やされるコードのごく一部しかありません。
Java では、いつでも JNI (Java ネイティブ インターフェイス) を使用して、計算負荷の高いコードを C モジュール (または、本当にパワーが必要な場合は SSE を使用したアセンブリ) に移動できます。したがって、Java を使用してコードを機能させるようにします。パフォーマンスの目標を達成できないことが判明した場合は、JNI を使用してください。
いずれにせよ、コードの 90% はおそらくグルー コードとアプリケーションのものです。ただし、そうするとクロスプラットフォーム機能の一部が失われることに注意してください. その JNI と一緒に暮らすことができれば、ネイティブ コードのパフォーマンスへの扉は常に開いたままになります。
Java は、多くのオーディオ アプリケーションに適しています。他のいくつかのポスターとは対照的に、私は Java オーディオを扱うのが楽しいと感じています。利用可能な API とリソースを、恐ろしく、ほとんど文書化されていない CoreAudio と比較すると、信者になるでしょう。Java オーディオには遅延の問題がありますが、多くのアプリではこれは無関係であり、コーデックが不足しています。また、時間をかけずに優れたオーディオ再生エンジンを作成し (ヒント、決して SourceDataLine を閉じず、代わりに 0 を書き込みます)、問題を Java のせいにする人もたくさんいます。API の観点から見ると、Java オーディオは非常に単純で使いやすく、 jsresources.orgには非常に多くのガイダンスがあります。
もちろん？
重要な質問 (言語とは関係なく、これは待ち行列理論によるものです) は次のとおりです。
プログラムが平均的なスループットに追いつくことができ、待ち時間に十分な余裕がある場合は、入力と出力にキューを使用できるはずです。タイミングにとって重要なプログラムの部分は、データを入力キューに入れ、出力キューから取り出して、DAC /スピーカーなどに送信します。
遅延線は計算負荷が低く、必要なのは十分なメモリ (+ メモリ帯域幅) だけです...実際には、おそらく入力/出力キューを使用する必要があります。つまり、データをすぐに入力キューに入れ始め、データの取り出しを開始します。出力キューの 30 秒後。そこにない場合は、プログラムが遅すぎます...)。
FIRはより高価です。他の醜い厄介な操作を念頭に置いていない限り、それがおそらくボトルネック（および最適化したいもの）になるでしょう。
レイテンシーが主な問題になると思います。最新の OS の C/C++ で既にレイテンシーを維持することは非常に難しく、Java は確実に問題 (ガベージ コレクター) に追加されます。「リアルタイム」オーディオ処理の一般的な設計は、処理スレッドをリアルタイム スケジューリング (Linux カーネルでは SCHED_FIFO、他の OS では同等) で実行することであり、これらのスレッドは決してブロックされません。これは、システムコール、malloc、IO などがないことを意味します... ページングでさえ問題です (ディスクからメモリにページを取得するのに数ミリ秒かかることがあります)。交換しました。
これらのことは Java でもできるかもしれませんが、Java はそれをより複雑にしますが、簡単にはしません。必要に応じて、コアが C であり、残り (GUI など) が Java である混合設計を検討します。
私があなたの質問で見なかったことの1つは、これらの処理されたサンプルを再生する必要があるのか、それとも他のことをしているのか（たとえば、ファイルにエンコードするのか）です。JVMがサンプルを処理する速度よりも、Javaのサウンドエンジンの状態について心配します。
私は数年前にjavax.sound.sampledをかなり強く押して、感動せずに離れました-OpenALやMac / iPhoneのCoreAudio（どちらも同じレベルで使用した）のような同等のフレームワークとは比較できません強度）。javax.sound.sampledでは、サンプルを期間が不明な不透明なバッファーにプッシュする必要があります。これにより、同期がほぼ不可能になります。また、十分に文書化されておらず（メモリ内のクリップの些細な例とは対照的に、ライン上で不確定な長さのオーディオをストリーミングする例を見つけるのは非常に困難です）、実装されていないメソッド（DataLine.getLevel（）...が実装されていません。文書化されていても）、そしてそれを締めくくりに、Sunは数年前に最後のJavaSoundエンジニアを解雇したと思います。
サウンドのミキシングと出力にJavaエンジンを使用する必要がある場合は、少なくともエンジンが現在サポートされており、非常に低レイテンシーであることがわかっているので、OpenALへのJOALバインディングを最初の選択肢として使用しようと思います。 。長い目で見れば、Nilsは正しいと思いますが、最終的にはJNIを使用してネイティブサウンドAPIを呼び出すことになります。
はい、Java はオーディオ アプリケーションに最適です。Java を使用し、Asio 経由でオーディオ レイヤーにアクセスでき、Windows プラットフォームで非常に低いレイテンシー (64 サンプルのレイテンシーはほとんどありません) を実現できます。これは、ビデオ/映画でリップシンクが発生することを意味します。OS X と「Java on top」の組み合わせを「ショートカット」するための Asio がないため、Mac ではレイテンシが長くなりますが、それでも問題ありません。Linuxもそうですが、私はもっと無知です。Java と Asio が完全に調和して動作する実用的な (そして世界初の) 例については、soundpimp.com を参照してください。sw mp3 デコーダー (Java から) を含む NRK Radio&tv Android アプリも参照してください。ほとんどのオーディオ処理は Java で行うことができ、さらに時間が重要な場合はネイティブ レイヤーを使用できます。
Jsyn というライブラリを調べてください。
1 日かけて、最小限の処理を行う単純な Java アプリケーションを作成し、パフォーマンスが適切かどうかを検証してみませんか。