Sox parando depois de uma quantidade específica de bytes

1

Meu objetivo é ter uma ferramenta de linha de comando para gravar arquivos wav multicanais longos em um raspberry pi 3 (5 horas + 18 canais). Interface de áudio é o Behringer XR18 .

A maneira de fazer isso é, claro, via arecord , que infelizmente produz buffer overruns no pi. Como arecord tem um max fixo tamanho de buffer de 500 ms, que não posso / não quero alterar, canalizo a saída do arecord para sox, que por sua vez grava em uma unidade flash USB ntfs. Como um benefício adicional, o sox converte as amostras de 32 a 24 bits de forma rápida e elimina os excessos (até onde eu posso ver).

Aqui está o comando que eu executo:

arecord -M -D hw:CARD=X18XR18,DEV=0 -c18 -f S32_FE -r48000 | sox --input-buffer 51200 -t wav - -b24 -c18 -t wav <filename.wav>

A primeira parte até o pipe | funciona, não é necessária ajuda. A segunda parte também funciona, o arquivo é criado e cresce à medida que a gravação avança. Mas por algum motivo, por volta de 1,5 GB, a gravação é interrompida e sai do sox.

Executar arecord sozinho não tem essa restrição, ele é executado por horas e horas (com excessos, é claro).

Notei que, pouco antes de chegar ao tamanho final do arquivo, o arquivo para de crescer continuamente, mas permanece por algum tempo e depois cresce em alguns MB. Isso soa terrivelmente como um buffer saturado para mim, mas dobrar o tamanho do buffer de sox para 100 MB não fez diferença alguma. A saída do sox também não é muito útil, mesmo no nível detalhado 3 mostra apenas:

sox WARN sox: '<filename>' output clipped 13403 samples; decrease volume?
sox WARN sox: '-' balancing clipped 13403 samples; decrease volume?

O que eu tentei até agora:

  • Alterou o --input-buffer-size do sox - nenhuma diferença
  • tentou iniciar um novo arquivo antes de 1,5 GB - funciona, mas assim que o tamanho de arquivo adicionado atinge 1,5 GB, ele para novamente
  • gravado diretamente no cartão SD em vez de flash drive - não há diferença (além de introduzir excessos)

Eu não tenho uma máquina linux diferente para testá-lo em atm, mas o raspberry pi 3 deve ser totalmente capaz de lidar com essa tarefa (cpu / ram-wise). Alguém tem uma dica sobre o que pode estar causando esse comportamento estranho?

    
por thmshrn 14.01.2017 / 05:57

1 resposta

0

Este tópico diz para tentar usar um disco de destino formatado em xfs / Cartão SD.

    
por 11.03.2017 / 17:09