Entrada Fast Audio / Output

Question

Aqui está o que eu quero fazer:

Eu quero permitir que o usuário dar o meu programa de alguns dados de som (através de uma entrada de microfone), em seguida, mantê-lo por 250ms, então a saída para trás para fora através dos altifalantes.

Eu tenho feito isso já usando a API Java Sound. O problema é que é sorta lento. É preciso um mínimo de cerca de 1-2 segundos a partir do momento o som é feito para o tempo que o som é ouvido novamente a partir dos alto-falantes, e eu nem sequer tentou implementar a lógica de atraso ainda. Teoricamente não deve haver nenhum atraso, mas não há. Eu entendo que você tem que esperar para a placa de som para encher o buffer ou o que quer, e o tamanho da amostra ea taxa de amostragem ter algo a ver com isso.

A minha pergunta é esta: Devo continuar o caminho Java tentando fazer isso? Eu quero começar o atraso até como 100ms, se possível. Alguém tem experiência usando o driver ASIO com Java? Supostamente é mais rápido ..

Além disso, eu sou um cara .NET. Será que isso faz sentido para fazer com .NET em vez disso? E sobre C ++? Eu estou procurando a tecnologia certa para usar aqui, e talvez um bom exemplo de como a leitura / gravação para a entrada / saída de áudio fluxos usando sua plataforma de tecnologia sugeriu. Obrigado pela sua ajuda!

Answer 1

Eu usei JavaSound no passado e achei maravilhosamente escamosa (e continua a mudar entre versões VM). Se você gosta de C #, usá-lo, basta usar as APIs do DirectX. Aqui está um exemplo de fazer o tipo do que você quer fazer usando DirectSound e C #. Você pode usar os plugins Effects para executar seus 250 ms de eco.

http://blogs.microsoft.co.il/blogs/tamir/archive/2008/12/25/capturing-and-streaming-sound-by-using-directsound-with-c aspx

Answer 2

Você pode querer olhar para JACK , uma API de áudio projetado para processamento de som de baixa latência. Além disso, o Google transforma-se este bacana apresentação [PDF] sobre o uso do JACK com Java .

Teoricamente não deve haver nenhum atraso, mas existe.

Bem, é impossível ter zero de atraso. O melhor que você pode esperar é um atraso imperceptível (em termos de percepção humana). Pode ajudar se você descrever seu algoritmo básico para a leitura e gravação dos dados de som, para que as pessoas possam identificar possíveis problemas.

Um problema potencial com o uso de uma linguagem de coleta de lixo como Java é que o GC periodicamente executado, interrompendo o seu processamento para uma certa quantidade de tempo arbitrário. No entanto, eu ficaria surpreso se ele é> 100ms em uso normal. Se GC é um problema, a maioria das JVMs fornecer algoritmos de coleta de alternativas que você pode tentar.

Answer 3

Se você optar por ir para baixo o caminho do C / C ++, eu recomendo usar PortAudio ( http://portaudio.com/ ). Ele funciona com quase tudo em múltiplas plataformas e dá-lhe o controle de baixo nível dos drivers de som sem realmente ter que lidar com os vários tecnologia de driver de som que está ao redor.

Eu usei PortAudio em vários projetos, e é uma verdadeira alegria para usar. E a licença é permissiva.

Answer 4

Se baixa latência é o seu objetivo, você não pode bater C.

libsoundio é uma biblioteca de baixo nível C para entrada de áudio em tempo real e saída. Ele ainda vem com um exemplo de programa que faz exatamente o que você quer -. canalizando a entrada de microfone para a saída alto-falantes

Answer 5

É certamente possível com JavaSound para obter uma extremidade à outra latência no estádio de 100-150ms.

1. A causa primária da latência é os tamanhos de memória intermédia das linhas de captura e reprodução. O tamanho é definido quando a abertura das linhas de:

   • captura: TargetDataLine#open(AudioFormat format, int bufferSize)
   • reprodução: SourceDataLine#open(AudioFormat format, int bufferSize)

Se o buffer é muito grande, irá causar excesso de latência, mas se for muito pequena que irá causar a reprodução stuttery. Então, você precisa encontrar um equilíbrio para as suas aplicações necessidades e seu poder de computação.

O tamanho do buffer padrão pode ser verificado com DataLine#getBufferSize ao chamar #open(AudioFormat format). O tamanho padrão varia de acordo com o AudioFormat e parece ser voltado para alta latência, aplicativos de reprodução sem gaguejar (por exemplo internet streaming). Se você está desenvolvendo um aplicativo de baixa latência, o tamanho do buffer padrão é muito grande e deve ser alterado.

Na minha teste com um AudioFormat PCM 16-bit, um tamanho do buffer de 1024 bytes tem sido muito próximo do ideal para baixo latência.

2. O segundo e muitas vezes esquecido causa de latência de áudio é qualquer outra atividade que está sendo feito na captura ou reprodução threads. Por exemplo, mensagens de log a consola pode apresentar 10 dos ms de latência. Desligá-lo.