有许多基于时间的应用程序示例，它们以非常精细的分辨率和准确性发送事件或执行复杂的处理。想想 MIDI 音序应用程序、音频和视频编辑应用程序。
所以我很好奇，在它们的核心层面，这些应用程序如何从编程的角度准确地完成它们所做的事情？
最佳答案
MIDI 和媒体播放在本质上完全不同，并且以不同的方式处理。
对于 MIDI，需要处理的数据非常少。创建一个具有高优先级的线程来处理 MIDI I/O。这就是所有需要的。
对于音频，准确性不是问题，但延迟才是问题。声音接口(interface)上有一个缓冲区，播放音频的软件会定期写入该缓冲区。对于典型的媒体播放器，此缓冲区可存储大约 300 毫秒的音频。该软件只是将 PCM 编码的音频波形写入缓冲区。声音接口(interface)不断地从这个缓冲区中读取并以恒定的速率播放。
对于低延迟音频应用程序，此缓冲区大小可以非常小，处理低至 5 或 10 毫秒的音频。生成音频数据的软件必须再次由具有高优先级的线程处理，并且通常具有许多优化以使其在其余软件(效果和其他)无法跟上的情况下保持运行。缓冲区欠载很常见。特殊驱动程序通常用于跳过信号链中不需要的软件。 ASIO 和 DirectX 在 Windows 上很常见。 Windows Vista/7 和 OSX 都将它们的音频 API 称为“核心音频”，并提供低延迟特性而无需特殊驱动程序。
视频是完全不同的野兽。在可能的情况下，视频解码由硬件处理。这就是手机等慢速设备能够播放 720p 视频的方式。如果硬件可以处理编解码器，则软件只需要将数据发送给它。在不支持编解码器的情况下，视频必须在慢得多的软件中解码。即使在现代 PC 上，软件解码也经常导致视频断断续续或滞后。
音频到视频的同步也是一个问题。我对此了解不多，但据我了解，音频是主时钟，视频与之同步。您不能简单地开始播放并期望时间能够解决，因为不同的声音接口(interface)对于 44.1kHz(或任何其他采样率)是什么会有不同的想法。您可以通过同时在两个不同的设备上播放相同的音频并随着时间的推移聆听它们逐渐分离来证明这一点。
关于audio - 媒体时间线应用程序如何在后台工作？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14884763/