`mencoder` captures 10 minutes of audio in less than 10 minutes. How come?

Question

I'm using mencoder to capture audio from a Encore ENLTV-FM3 video capture device. I have recently noticed that, since one week ago, when the machine was forcibly restarted due to a power outage, all recordings are slightly pitched, they play back slower than they should.

I narrowed down the problem to the following command line:

$ 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

Somehow, mencode managed to gather precisely 10 minutes worth of raw audio in 9m 55s. That's not physically possible, unless the capture device's A/D converters are "overclocked". I can't think of any other explanation besides hardware failure. Can that be? Could it be that something got burnt during the power outage and now the capture device's internal clock went nuts?

Since the machine's restart, I've also noticed dmesg is flooded with entries like this:

CE: hpet increased min_delta_ns to XXX nsec

Which seem to indicate that the computer's high precision event timer is somehow out of sync. Does this have to do with the audio issue? Can it be that the audio converter's sample rate is linked to the HPET? I'm totally lost here. Has anyone bumped into something similar?

Answer 1

You provide minimal information. That is not very helpful. You should provide:

1. Kernel version
2. Are there any customisations? what is .mplayer/config
3. what is min_delta_ns?
4. what is the output of cat /proc/timer_list

Here are my guesses based on this limited information:

One of the below or a combination:

1. Updates have been applied onto your machine
2. mplayer is using RTC instead of hpet .
3. min_delta_ns is larger than 3.000.000 nsec

I think mplayer using RTC is the most probable case. Try appending to your options during encoding and playback:

-rtc-device /dev/hpet

Try to force both during encoding and playback.

If this still does not solve the problem, try using

-rtc-device /dev/rtc

but this does not really fit my view of your problem.

Answer 2

You've set audiorate=32000, are you sure this is working correctly? Is the card actually switching to a 32kHz sample rate? Is the output file 32kHz? What happens if you try audiorate=33075 (which seems to be the next logical step between 22050 and 44100.)

It is possible it's a firmware issue or something odd in the hardware that didn't initialise correctly, but doing a graceful shutdown + power off then restarting should fix that.

Otherwise you'll probably have to remove -really-quiet and see if there are any helpful warnings shown.