Canalizando som ao vivo do Raspberry Pi para o macOS

Eu realmente não posso dizer o que há de errado com sua configuração no seu caso específico; você gostaria de verificar se você ncrealmente recebe dados (por exemplo, gravando em um arquivo ou canalizando pv) e se arecordrealmente captura som (gravando em um arquivo em vez de canalizar para nc).

Além disso, não tenho certeza se 44100 Hz é uma taxa de amostragem elegante; a maior parte do hardware hoje em dia faz nativamente 48.000 e você está apenas deixando o ALSA converter isso para 44.100 Hz.

O que é mais importante é que você provavelmente deve usar um estruturador de transporte sensato, para permitir que a extremidade receptora alinhe adequadamente o tempo, compense a queda, descarte atrasado ou reordene pacotes, aprenda sobre o formato do fluxo em si. Eu uso MPEG Transport Stream como formato de stream, usado por coisas como transmissão de vídeo digital e outras plataformas de streaming multimídia.

Depois disso, usar o TCP para transporte de baixa latência provavelmente também não é uma boa ideia. Você também desejará limitar o tamanho do buffer de transmissão usado pelo coletor de rede (neste caso, no ncRPi). Resumindo, arecord | nc pode simplesmente não ser a melhor abordagem de streaming. Além disso, em sua abordagem, você obtém pelo menos a latência necessária para o terminal receptor iniciar depois que o remetente for iniciado e estiver pronto para se conectar

O que eu faço quando capturo rapidamente algum áudio e preciso colocá-lo em uma máquina diferente, principalmente por motivos de webconferência, é fazer o seguinte na "máquina de microfone":

ffmpeg \
  -f alsa -channels 1  -sample_rate 24000 -i pipewire \
  -f mpegts -max_packet_size 1024 \
  -c:a libopus -b:a 64k -vbr off -packet_loss 10 -fec on \
  udp://127.0.0.1:1234

vamos desmontar isso:

• ffmpeg: o programa que estamos executando, FFmpeg. Praticamente a solução padrão de transcodificação/streaming/decodificação na maioria das plataformas.

opções de entrada:

• -f alsa: o tipo de entrada ("formato") é alsa, ou seja, estamos captando o som do sistema de som alsa
• -channels 1: opcional Eu só quero som mono. Evite usar o que seu dispositivo de som oferece (provavelmente estéreo?) ou defina um valor diferente se desejar capturar especificamente um número diferente de canais
• -sample_rate 24000: opcional Estou mais preocupado com a fala, nesse caso uma taxa de amostragem de 24 kHz é muito mais que suficiente para uma excelente qualidade de áudio (não sou um morcego, minha voz não ultrapassa muito 1,2 kHz…).
• -i pipewire: captura do pipewiredispositivo ALSA. No seu caso, plughw:3,0ao que parece. (verifique os dispositivos de captura disponíveis com arecord -L)

opções de formato de saída:

• -f mpegts: depois de -iterminarmos de descrever a entrada, isso -fdescreve o formato de saída. Estamos transmitindo fluxo de transporte MPEG.
• -max_packet_size 1024: opcional forçamos o streamer a emitir um pacote a cada 1024 bytes. Isso limita a latência do lado da transmissão

opções de codec de áudio: opcional

• -c:a libopus: opcional c é a abreviação de codec, apara , and here we use the codificador de áudio libopus. OPUS é um codificador de áudio maduro, padrão da web, com baixa complexidade e configurações de alta qualidade.
• -b:a 64k: opcional , mas estamos definindo a taxa de bits codificada para 64kb/s. Isso é de qualidade bastante alta, mas bastante bom em termos de poder de computação (pense em 5% a 20% de um núcleo, no máximo)
• -vbr off: Constante de força opcional (em oposição à vtaxa de bits ariável). Isso faz sentido se você planeja transmitir em um link de largura de banda limitada e não pode ter codificação com picos curtos de alta taxa. Omitir na LAN.
• -packet_loss 10: opcional, configure a redundância em pacotes de forma que não haja problema se 1 em cada 10 pacotes for perdido. Torna isso robusto em conexões com quedas ocasionais de pacotes, como algumas conexões de Internet, algumas conexões sem fio, etc. Omitir em LAN.
• -fec on: opcional após definir o valor da redundância, também queremos ativar o envio dessa redundância para fins de correção de erros futuros . Só faz sentido com > 0.-packet_loss

opções de saída:

• udp://127.0.0.1:1234Endereço IP e porta para transmitir. Atenção! Aqui o receptor é a parte de audição e o transmissor é um soquete UDP, então ele apenas envia o fluxo de áudio sem se importar se alguém o capta. A vantagem aqui é que você pode conectar e desconectar o receptor quantas vezes quiser.

No lado receptor, abriremos um soquete de escuta:

ffplay -f mpegts -nodisp -fflags nobuffer udp://127.0.0.1:1234

-nodispvoltas da tela (não estamos transmitindo vídeo), -fflags nobufferfaz com que o analisador de fluxo de entrada não tente acompanhar coisas antigas (ou seja, evita o atraso do "ouvinte tardio" que você não teria).

Observe que, neste cenário, o terminal de reprodução é o servidor, que abre o soquete de escuta (como você nc -lfez). Você também pode reverter isso, se quiser, usando zmq:tcp://onde você usou udp://em ambos os lados antes, e obter a capacidade de conectar vários ouvintes ao seu pi "gravador" de serviço.

É claro que você também é absolutamente livre para usar nc -u -l -p 1234 | … um …programa que entenda MPEG TS.