☰

`mencoder` 可以在不到 10 分钟的时间内捕获 10 分钟的音频。这是为什么呢？

tag-icon • tag-icon linux audio mplayer mencoder
`mencoder` 可以在不到 10 分钟的时间内捕获 10 分钟的音频。这是为什么呢？

我用来mencoder捕捉来自安可 ENLTV-FM3视频捕获设备。我最近注意到，自一周前由于断电而强制重启机器以来，所有录音都略有失真，播放速度也比应有的速度慢。

我将问题缩小到以下命令行：

$ 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

不知怎么的，竟然mencode能在 9 分 55 秒内精确收集到 10 分钟的原始音频。这在物理上是不可能的，除非捕获设备的 A/D 转换器“超频”。除了硬件故障，我想不出任何其他解释。会这样吗？会不会是断电时有东西烧坏了，导致捕获设备的内部时钟失灵？

自从机器重新启动以来，我还注意到dmesg充斥着如下条目：

CE: hpet increased min_delta_ns to XXX nsec

这似乎表明计算机的高精度事件计时器不知何故不同步。这与音频问题有关吗？音频转换器的采样率是否与 HPET 有关？我完全搞不懂。有人遇到过类似的事情吗？

答案1

您提供的信息很少。这没什么帮助。您应该提供：

  1. 内核版本
  2. 有任何定制吗？.mplayer/config 是什么
  3. min_delta_ns 是什么？
  4. cat /proc/timer_list 的输出是什么

根据这些有限的信息，我做出了以下猜测：

以下之一或其组合：

  1. 更新已应用到您的机器
  2. mplayer 使用 RTC 而不是 hpet 。
  3. min_delta_ns 大于 3.000.000 纳秒

我认为 mplayer 使用 RTC 是最可能的情况。尝试在编码和播放期间附加到您的选项中：

-rtc-device /dev/hpet

尝试在编码和播放期间强制执行。

如果这仍然不能解决问题，请尝试使用

-rtc-device /dev/rtc

但这确实不符合我对你的问题的看法。

答案2

您已设置 audiorate=32000，您确定它正常工作吗？卡是否真的切换到 32kHz 采样率？输出文件是 32kHz 吗？如果您尝试 audiorate=33075（这似乎是 22050 和 44100 之间的下一个合乎逻辑的步骤），会发生什么。

这可能是固件问题，或者是硬件中某些未正确初始化的异常，但正常关机 + 关闭电源然后重新启动应该可以解决这个问题。

否则，您可能必须删除 -really-quiet 并查看是否显示任何有用的警告。

相关内容