假设我播放的立体声WAV文件包含317,520,000个样本，理论上 1小时。假设播放没有中断，文件将在完全一小时内完成播放，或者播放速度是否会偶尔出现微小的变化，这样会略微增加或稍微减少（按某些数量）毫秒）超过一小时？
我正在尝试将动画与音频同步，我正在使用System.Diagnostics.Stopwatch来保持帧与音频匹配。但是，如果Windows中WAV音频的播放速度随着时间的推移会略有不同，那么音频将与秒表驱动的动画不同步。
这导致了第二个问题：Stopwatch - 虽然在短时间内非常精细且准确 - 但运行速度稍快。在我的笔记本电脑上，Stopwatch运行24小时（通过计算机的系统时间和真正的秒表测量）显示24小时的经过时间加上大约5秒（不是毫秒）
这是Stopwatch的已知问题吗？ （一个相关的问题是“我疯了吗？”，但你可以自己尝试一下。）鉴于它作为诊断工具的用途，我可以看到这样的差异只会在测量长持续时间时出现，其中大多数人们会使用Stopwatch以外的其他内容。
如果我真的很幸运，那么Stopwatch和音频播放都是由相同的底层机制驱动的，因此会在几天内保持同步。这是真的吗？
更新：我刚刚做了数学计算，如果Stopwatch在24小时内漂移了5秒，这意味着它会在172秒后漂移10毫秒。因此，在3分钟内，动画将开始明显不同步。
我正在周期性地（每10秒钟左右）尝试从waveOutWrite回调中重新启动计时器，但这不起作用，因为随后回调的整个下一组计时器事件都会被回调的不准确性所抵消碰巧是。很难成为我。
答案 0 :(得分：2)
没有时钟会“精确”地测量时间，因为所有物理设备都必然会有一些变化和测量误差。这意味着所有时钟都会略微过快或过慢（尽管误差量可能会有很大差异，具体取决于时钟）。
在您的情况下，音频输出由驱动DAC的声卡上的时钟驱动。我不知道.NET平台，但我认为秒表是某种系统计时器，这意味着它是由一个不同的时钟驱动（主板上的那个，大概是）。
现在一般情况下，由于上述原因，两个不同的物理时钟永远不会以完全相同的速度运行。这就是你得到的差异来自哪里。您的动画也会发生同样的事情 - 您可以绝对不会假设系统时钟和声卡DAC时钟相同 - 它们会有所不同！
这意味着如果要保持两个流（视频和音频）同步，它们必须由相同的时钟驱动。由于您无法更改驱动声卡的时钟，因此将所有内容同步到声卡是一个不错的选择。
答案 1 :(得分：0)
Larry Osterman在评论中提供了答案：
FWIW，在Windows中视频时钟是 由音频时钟驱动。如果你是 渲染音频，你得到音频 时钟通过调用waveOutGetPosition （因为音频是同步的，所以 立场是直接腐蚀的 时间）。所有其他音频渲染 API具有类似的“GetPosition”API 可以用来确定 音频渲染位置。