'mencoder' captura 10 minutos de áudio em menos de 10 minutos. Por quê?

Question

Estou usando mencoder para capturar áudio de um vídeo Encore ENLTV-FM3 dispositivo de captura. Recentemente notei que, desde uma semana atrás, quando a máquina foi reiniciada à força devido a uma falta de energia, todas as gravações são levemente inclinadas, elas são reproduzidas mais lentamente do que deveriam.

Limitei o problema para a seguinte linha de comando:

$ time mencoder -really-quiet -tv driver=v4l2:device=/dev/video1:chanlist=us-cable:audiorate=32000:alsa:adevice=hw.1:input=0:amode=1:normid=11 -endpos 00:10:00 -ovc copy -oac pcm -of rawaudio -o test-32000.wav  tv://69

real    9m54.886s
user    0m5.536s
sys    0m1.740s

$ ls -l test-32000.wav 
-rw-r--r--@ 1 martin  martin  76800000 Mar 15 17:20 test-32000.wav

De alguma forma, mencode conseguiu reunir precisamente 10 minutos de áudio bruto em 9m 55s. Isso não é fisicamente possível, a menos que os conversores A / D do dispositivo de captura tenham um "overclock". Não consigo pensar em nenhuma outra explicação além de falha de hardware. Pode ser isso? Pode ser que algo tenha sido queimado durante a falta de energia e agora o relógio interno do dispositivo de captura enlouqueceu?

Desde o reinício da máquina, também notei que dmesg está inundado com entradas como esta:

CE: hpet increased min_delta_ns to XXX nsec

Quais parecem indicar que o timer de eventos de alta precisão do computador está de alguma forma fora de sincronia. Isso tem a ver com o problema de áudio? Pode ser que a taxa de amostragem do conversor de áudio esteja vinculada à HPET? Estou totalmente perdida aqui. Alguém já esbarrou em algo semelhante?

    

Answer 1

Você fornece informações mínimas. Isso não é muito útil. Você deve fornecer:

1. Versão do kernel
2. Há alguma customização? o que é .mplayer / config
3. o que é min_delta_ns?
4. qual é a saída de cat / proc / timer_list

Aqui estão meus palpites com base nessa informação limitada:

Um dos abaixo ou uma combinação:

1. Atualizações foram aplicadas em sua máquina
2. O mplayer está usando o RTC em vez do hpet.
3. min_delta_ns é maior que 3.000.000 nsec

Eu acho que o mplayer usando o RTC é o caso mais provável. Tente adicionar suas opções durante a codificação e a reprodução:

-rtc-device /dev/hpet

Tente forçar os dois durante a codificação e a reprodução.

Se isso ainda não resolver o problema, tente usar

-rtc-device /dev/rtc

mas isso não se encaixa na minha opinião sobre o seu problema.

    

Answer 2

Você definiu audiorate = 32000, tem certeza de que isso está funcionando corretamente? A placa está realmente mudando para uma taxa de amostragem de 32kHz? O arquivo de saída é 32kHz? O que acontece se você tentar audiorate = 33075 (que parece ser o próximo passo lógico entre 22050 e 44100).

É possível que seja um problema de firmware ou algo estranho no hardware que não inicializou corretamente, mas fazer um desligamento normal + desligar e reiniciar deve corrigir isso.

Caso contrário, você provavelmente terá que remover -really-quiet e ver se há algum aviso útil mostrado.