Java pour le traitement audio est-il pratique?

Question

Java est-il une alternative appropriée au C / C ++ pour le traitement audio en temps réel?

J'envisage une application avec ~ 100 (au maximum) pistes audio avec lignes à retard (30s @ 48khz), filtrage (FIR à 512 points?) et autres opérations de type DSP simultanées sur chaque piste.

Les opérations seraient converties et effectuées en virgule flottante.

Le système serait probablement un quad core 3 GHz avec 4 Go de RAM, fonctionnant sous Ubuntu.

J'ai vu des articles sur Java beaucoup plus rapides qu'auparavant, se rapprochant du C / C ++ et maintenant dotés d'extensions temps réel. Est-ce la réalité? Faut-il coder et ajuster durement pour atteindre les performances de 50% à 100% de C certaines spécifications?

Je cherche vraiment à savoir si cela est possible et à prendre les devants.

Answer 1

Pour une application audio, vous ne disposez souvent que de très petites parties de code sur lesquelles vous passez la plupart du temps.

En Java, vous pouvez toujours utiliser le JNI (interface native Java) et déplacer votre code informatique lourd dans un C-module (ou un assemblage utilisant SSE si vous avez réellement besoin de puissance). Je dirais donc que vous utilisez Java et que votre code fonctionne. S'il s'avère que vous n'atteignez pas votre objectif de performance, utilisez JNI.

90% du code sera très probablement du code collé et des applications. Mais gardez à l'esprit que vous perdez certaines des fonctionnalités multi-plateformes de cette façon. Si vous pouvez vivre avec cela, JNI vous laissera toujours la porte ouverte pour des performances en code natif.

Answer 2

Java convient à de nombreuses applications audio. Contrairement à d'autres affiches, je trouve que l'audio Java est un plaisir pour moi. Comparez l’API et les ressources dont vous disposez à l’esprit effroyable et à peine documenté de CoreAudio et vous serez un croyant. L'audio Java souffre de certains problèmes de latence, bien que cela ne soit pas pertinent pour de nombreuses applications et de codecs. Il y a aussi beaucoup de gens qui n'ont jamais pris la peine de prendre le temps d'écrire de bons moteurs de lecture audio (conseil, ne fermez jamais un SourceDataLine, écrivez plutôt des zéros), et blâmerez ensuite Java pour ses problèmes. Du point de vue des API, l’audio Java est très simple, très facile à utiliser, et il existe de nombreuses indications à l'adresse jsresources. .org .

Answer 3

Bien sûr, pourquoi pas?

Les questions cruciales (indépendantes de la langue, c’est de la théorie des files d’attente) sont les suivantes:

• quel est le débit maximum que vous devez gérer (vous avez spécifié 100 x 48 kHz, est-ce mono ou stéréo, combien de bits sont équivalents à cette fréquence?)
• vos routines Java peuvent-elles suivre ce taux en moyenne?
• quelle est la latence maximale admissible?

Si votre programme parvient à suivre le débit moyen et que vous disposez de suffisamment de place pour la latence, vous devriez pouvoir utiliser les files d'attente pour les entrées et les sorties, et les seules parties du programme critiques pour le minutage sont: les pièces qui placent les données dans la file d’entrée, puis les sortent de la file de sortie et les envoient à un DAC / haut-parleur / peu importe.

Les lignes de retard ont une charge de calcul faible, vous avez juste besoin de suffisamment de mémoire (+ bande passante mémoire) ... en fait, vous devriez probablement simplement utiliser les files d’entrée / sortie, c’est-à-dire commencer à mettre immédiatement les données dans la file d’entrée, et commencer prendre des données de la file d'attente de sortie 30s plus tard. Si ce n’est pas le cas, votre programme est trop lent ...).

Les FIR sont plus chers, ce sera probablement le goulot d'étranglement (et ce que vous voudriez optimiser) à moins que vous ne pensiez à une autre opération laide et méchante.

Answer 4

Je pense que la latence sera votre principal problème - il est assez difficile de maintenir la latence déjà en C / C ++ sur les systèmes d’exploitation modernes, et java ajoute certainement au problème (ramasse-miettes). La conception générale de " temps réel " Le traitement audio consiste à exécuter vos threads de traitement selon une planification en temps réel (SCHED_FIFO sur les noyaux Linux, équivalent sur d'autres systèmes d'exploitation), et ces threads ne doivent jamais se bloquer. Cela signifie qu’il n’ya pas d’appel système, pas de malloc, pas d’IO bien sûr, etc ... Même la pagination pose un problème (le transfert d’une page d’un disque à une autre peut facilement prendre plusieurs ms); échangé.

Vous pouvez peut-être faire ces choses en Java, mais Java rend les choses plus compliquées, pas plus faciles. J'examinerais une conception mixte, où le noyau serait en C et le reste (interface graphique, etc.) en java si vous voulez.

Answer 5

Une chose que je n’ai pas vue dans votre question est de savoir si vous devez reproduire ces échantillons traités ou si vous faites autre chose avec eux (les encoder dans un fichier, par exemple). Je serais plus préoccupé par l'état du moteur de son de Java que par la rapidité avec laquelle la JVM peut traiter des échantillons.

J'ai beaucoup insisté sur javax.sound.échantillonné quelques années en arrière et je suis resté profondément impressionné - cela ne se compare pas aux frameworks équivalents comme OpenAL ou le Core Audio pour Mac / iPhone (que j'ai déjà utilisés à une niveau d'intensité similaire). javax.sound.sampled vous oblige à placer vos échantillons dans un tampon opaque de durée inconnue, ce qui rend la synchronisation presque impossible. Elle est également mal documentée (il est très difficile de trouver des exemples de flux audio de longueur indéterminée sur une ligne, contrairement aux exemples triviaux de clips en mémoire), a des méthodes non implémentées (DataLine.getLevel () ... dont la non-implémentation n’est pas ' même documentée), et pour couronner le tout, je crois que Sun a licencié le dernier ingénieur JavaSound il y a des années.

Si je devais utiliser un moteur Java pour le mixage et la sortie audio, j'essaierais probablement d'utiliser les liaisons JOAL vers OpenAL en premier choix, car je connais au moins le moteur. était actuellement pris en charge et capable de très faible latence. Bien que je soupçonne à long terme que Nils est correct et que vous utiliserez JNI pour appeler l’API de son natif.

Answer 6

Oui, Java est idéal pour les applications audio. Vous pouvez utiliser Java et accéder aux couches audio via Asio et bénéficier d'une latence très faible (latence de 64 échantillons presque nulle) sur la plate-forme Windows. Cela signifie que vous aurez une synchronisation labiale sur vidéo / film. Plus de latence sur Mac, car il n'y a pas d'Asio vers "raccourci". la combinaison de OS X et de "Java en haut", mais toujours OK. Linux aussi, mais je suis plus ignorant. Voir soundpimp.com pour un exemple pratique (et une première mondiale) de Java et d'Asio travaillant en parfaite harmonie. Voir également l'application NRK Radio & tv Android contenant un décodeur sw mp3 (de Java). Vous pouvez faire la plupart des choses audio avec Java, puis utiliser une couche native si le temps supplémentaire est critique.

Answer 7

Découvrez une bibliothèque appelée Jsyn.

http://www.softsynth.com/jsyn/

Answer 8

Pourquoi ne pas passer une journée à écrire une application Java simple qui effectue un traitement minimal et à valider si les performances sont correctes.

Answer 9

De http://www.jsresources.org/faq_performance.html#java_slow

  

Collectons un peu de sagesse éternelle:

     

  

• La terre est plate.

  

• et, pour ne pas oublier: Java est lent.

  

     

Comme le prouvent plusieurs applications (voir la section des liens), Java suffit   construire des éditeurs audio, des systèmes d’enregistrement multipiste et MIDI   logiciel de traitement. Essayez-le!