Java para processamento de áudio é prático?

Question

Java é uma alternativa adequada para C ++ para processamento de áudio / C em tempo real?

Estou pensando em um aplicativo com ~ 100 (no máximo) faixas de áudio com linhas de atraso (30s @ 48kHz), filtrando (512 ponto FIR?), E outras operações do tipo DSP ocorrendo em cada pista ao mesmo tempo.

As operações seria convertido e realizada no ponto flutuante.

O sistema provavelmente seria um quad core de 3 GHz com 4 GB de RAM, rodando Ubuntu.

Já vi artigos sobre Java sendo muito mais rápido do que costumava ser, chegando perto de C / C ++, e agora ter extensões em tempo real também. É esta realidade? Será que requer codificação núcleo duro e afinação para alcançar a% 50-% 100 desempenho de C alguns são spec'ing?

Estou realmente procurando um sentido se isso é possível e um heads-up para alguma dicas.

Answer 1

Para um aplicativo de áudio que muitas vezes têm apenas pequenas partes do código onde a maior parte do tempo é gasto.

Em Java, você sempre pode usar o JNI (interface nativa Java) e mover o código pesado computacional em um módulo C (ou montagem usando SSE se você realmente precisa do poder). Então eu diria que o uso Java e obter o seu trabalho de código. Se acontece que você não conhecer o seu desempenho uso meta JNI.

90% do código provavelmente será código de cola e outras coisas aplicação de qualquer maneira. Mas tenha em mente que você perder alguma da plataforma cruzada apresenta dessa maneira. Se você pode viver com isso JNI vai sempre deixar-lhe a porta aberta para o desempenho de código nativo.

Answer 2

Java é bom para muitas aplicações de áudio. Ao contrário do que alguns dos outros cartazes, acho áudio Java uma alegria para trabalhar. Compare a API e os recursos disponíveis para você ao horrendo mindf e quase não documentado * k que é CoreAudio e você vai ser um crente. sofre de áudio Java de alguns problemas de latência, embora para muitos aplicativos isso é irrelevante, e uma falta de codecs. Há também muitas pessoas que nunca se preocupou em tomar o tempo para escrever bons motores de reprodução de áudio (dica, nunca fecham um SourceDataLine, em vez zeros escrever para ele), e, posteriormente culpar Java para os seus problemas. De um ponto de vista API, áudio Java é muito simples, muito fácil de usar, e há lotes e lotes de orientação sobre a jsresources .org .

Answer 3

Claro, porque não?

As perguntas cruciais (independente da linguagem, isto é de teoria das filas) são:

• o que é o máximo rendimento você precisa pega (você especificou 100 x 48 kHz, é que mono ou estéreo, quantos bits equivalentes a essa frequência?)
• Pode suas rotinas Java manter-se com esta taxa, em média?
• O que é a latência máxima permitida?

Se o seu programa pode manter-se com a taxa de transferência em média, e você tem espaço suficiente para a latência, então você deve ser capaz de usar filas para entradas e saídas, e as únicas partes do programa que são críticos para o sincronismo são as peças que colocam os dados para a fila de entrada e levá-la para fora da fila de saída e enviá-lo a um DAC / alto-falante / whatever.

linhas de atraso têm baixa carga computacional, você só precisa de memória suficiente (+ largura de banda de memória) ... na verdade, você provavelmente deve apenas usar as filas de entrada / saída para ela, ou seja, começar a colocar dados na fila de entrada imediatamente e começar tendo dados para fora dos 30s fila de saída posterior. Se ele não estiver lá, seu programa é muito lento ...).

FIR são mais caros, que provavelmente vai ser o gargalo (& o que você deseja otimizar) a menos que tenha alguma outra operação desagradável feio em mente.

Answer 4

Eu acho que a latência será o seu grande problema - é bastante difícil manter a latência já em C / C ++ em sistemas operacionais modernos, e java certamente contribui para o problema (coletor de lixo). O projeto geral para processamento de áudio "em tempo real" é ter seus threads de processamento rodando a programação em tempo real (SCHED_FIFO em kernels Linux, o equivalente em outros sistemas operacionais), e os fios nunca deve bloquear. Isto significa que não chamadas do sistema, não malloc, não IO é claro, etc ... Mesmo paginação é um problema (recebendo uma página do disco para a memória pode facilmente levar várias ms), assim você deve bloquear algumas páginas para ter certeza que eles nunca são trocados.

Você pode ser capaz de fazer essas coisas em Java, mas java torna mais complicado, e não mais fácil. Gostaria de olhar para um projeto misto, em que o núcleo seria em C, eo resto (GUI, etc ...) seria em java, se quiser.

Answer 5

Uma coisa que eu não vi na sua pergunta é se você precisa jogar fora essas amostras processadas ou se você está fazendo alguma coisa com eles (codificá-los em um arquivo, por exemplo). Eu estaria mais preocupado com o estado de motor de som de Java do que em quão rápido o JVM pode triturar amostras.

Eu empurrei muito duro com javax.sound.sampled alguns anos atrás e saiu profundamente impressionado - não se compara com as estruturas equivalentes, como OpenAL ou Core Audio iPhone / Mac (ambos de que eu usei em um nível semelhante de intensidade). javax.sound.sampled exige que você empurrar suas amostras em um buffer opaca de duração desconhecida, o que torna a sincronização quase impossível. É também pouco documentada (muito difícil encontrar exemplos de streaming de áudio indeterminado de comprimento através de uma linha ao contrário dos exemplos triviais de clipes em memória), tem métodos não implementados (DataLine.getLevel () ... cujos ISN-implementação não' t mesmo documentada), e ainda por cima, acredito Sun demitiu o último engenheiro JavaSound anos.

Se eu estiveste para usar um motor de Java para mixagem de som e saída, eu provavelmente tentar usar as ligações de Joal para OpenAL como primeira escolha, desde que eu tinha pelo menos saber o motor foi actualmente suportada e capaz de muito baixa latência. Embora eu suspeite que a longo prazo que Nils está correto e você vai acabar usando JNI para chamar a API de som nativo.

Answer 6

Sim, Java é ótimo para aplicações de áudio. Você pode usar Java e camadas de áudio de acesso via Asio e têm muito baixa latência (64 amostras latência que é quase nada) na plataforma Windows. Isso significa que você terá lip-sync em vídeo / filme. Mais latência no Mac como não há Asio para "atalho" a combinação de OS X e "Java em cima", mas ainda OK. Linux também, mas eu sou mais ignorante. Veja soundpimp.com para um exemplo prático (e primeira do mundo) de Java e Asio trabalhando em perfeita harmonia. Também ver a NRK Radio & TV App Android contendo um sw mp3 decodificador (de Java). Você pode fazer a maioria das coisas de áudio com Java, e, em seguida, usar uma camada nativa se tempo extra crítica.

Answer 7

Confira uma biblioteca chamada Jsyn.

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

Answer 8

Por que não passar um dia e escrever um aplicativo java simples que faz o processamento mínimo e validar se o desempenho é adaquate.

Answer 9

A partir http://www.jsresources.org/faq_performance.html#java_slow

Vamos cobrar alguma sabedoria ethernal:

• A terra é plana.

• e, para não esquecer:. Java é lento

Como vários aplicativos provar (ver seção de links), Java é suficiente para construir editores de áudio, sistemas de gravação multipista e MIDI software de processamento. Experimente!