修改sonar服务器时间,Cakewalk/Sonar的 midi 时间问题详解

[dvnews_page]

捣鼓硬盘时发现去年琢磨MIDI时间偏移的一些笔记， 整理整理贴上来， 希望对遇到这个问题的兄弟们有点用吧。

很多朋友发现从Win98升级到Win2000, WinXP后Cakewalk/Sonar出现录制MIDI音符提前或偏后的问题，造成这一现象的原因简单说有这么几个:

1.Windows里有好几个不同精度的时钟

2.音乐软件和硬件使用哪个时钟来计时没有硬性规定，程序员可以根据需要选择。

3.传统上MIDI软件根据MIDI硬件接口报告的时间来记录MIDI信号，一个MIDI信号进来以后， 哪怕MIDI软件已经走到00:00:10了，如果MIDI硬件接口报告现在是00:00:09, MIDI软件就把这个信号记录在现在刻度前1秒的位置。

解决办法：忽略MIDI硬件接口报告的时间，让Cakewalk/Sonar用自己的时钟记录MIDI信号。具体说就是升级到Sonar2.2以上版本。

对于有兴趣对这个问题来龙去脉了解深一点的朋友不妨看看以下的内容：

背景知识:

音乐软件及硬件驱动的编程先后有两大阵营：WindowsMultiMedia(也就是我们常见的MME), DirectX(主要是其中的DirectMusic部分)。在涉及到时钟问题时，WindowsMultiMedia提供一个精确到毫秒的时钟，编程时可以通过WinMultiMedia SDK的TimeGetTime(简称TGT)函数来调用。DirectMusic提供一个精确到微秒甚至纳秒的时钟，编程时可以通过VC++语言的QueryPerformanceCounter(简称QPC)函数来调用。

奔腾级CPU出来之前，音乐软件和多媒体硬件驱动程序要取得高精度时钟几乎都使用TGT函数，比如Cakewalk/Cubase, 声卡上的Gameport/MIDI口的Win98/Win95驱动等等。奔腾级CPU出来后， 由于CPU里新增了一个时间周期组件， 程序员们可以通过新的QPC函数来获取更高精度的时钟。对于Cakewalk/Cubase等软件厂商来说， 老的TGT已经够用了，没有动力重写程序。硬件厂商对它们产品的驱动程序也是类似态度。于是广大硬件，软件都使用TGT函数的时钟， 大家相安无事。这也是以前Win98环境下很少有人抱怨MIDI时间漂移的原因。

作为微软推出的DirectX体系的重要一环， DirectMusic标准意图部分取代WindowsMultiMedia体系， 给未来的音乐软件搭建一个更好的平台。为了提高音/视频处理的同步质量， 改善音乐软件及硬件驱动的计时精度，DirectMedia和DirectMusic提供了一个依赖CPU, 可以精确到微秒甚至纳秒的主时钟， 可以通过IReferenceclock之类的DirectX编程函数调用。 虽然微软没有明说，从计时的精度上分析，IReferenceclock与QueryPerformanceCounter应该都是调用奔腾级CPU上的那个时间周期组件，也就是说用的是同一个时钟。

Win95, Win98里头硬件的驱动程序基本上都是基于虚拟机编程， 电脑老玩家们可能记得虚拟设备驱动程序(VxD)这样的字眼。 微软为了迎接当时即将到来的Win2000和WinXP等32位操作系统， 一直在鼓励硬件厂商们着手编写Win32版本的驱动程序(WDM)。由于Win98/Me和Win2000处于历史交接阶段， Win98/Me勉强支持WDM, Win2000勉强兼容VXD。基本上厂商们提供的Win98驱动还是基于VXD, 因为给一个勉强支持WDM的系统重新写一个WDM版的驱动是吃力不讨好的活儿。而为Win2000提供的驱动，考虑到WinXP将彻底不兼容VXD，大家都开始从头写全新的WDM版驱动程序。这个时候程序员们都知道DirectX和VC++提供很好的时钟了，反正驱动程序要重写， 何不采用这个新的高精度时钟， 于是这些WDM驱动纷纷采用Ireferenceclock/QPC时钟。 另一方面， 软件厂商Cakewalk/Cubase的产品在Win2000, WinXP下照样能运行， 它们没有动力抛弃TGT改用QPC。 使用了这么多年， 自己的程序核心已经很成熟。 谁也不愿意为了提高一点计时精度贸贸然修改源代码。 于是从这个时期开始，硬件，软件开始使用不同的时钟了。一直以来MIDI软件都依赖MIDI硬件接口报告的时间来记录MIDI信号，由于从前大家都依赖一个时钟，没有任何MIDI时间偏移的问题， 现在开始各用各的时钟， 一旦两个时钟不完全同步， 就会出乱子。

下面这个例子就是这个问题在Cakewalk/Sonar里的具体表现(以SB Live的MIDI端口为例)：

Cakewalk里调用的SB Live Midi In/Out端口使用QPC时钟

Cakewalk用传统的TGT时钟，在我的电脑上，TGT比QPC时钟稍快。

Cakewalk启动后立即启用SB Live MIDI In端口, 于是QPC与TGT两个时钟同时开始计时。

我们现在开始录音， 在第二小节开头我们弹了一个MIDI音符， 假设这时Cakewalk的TGT时钟刚好走到60秒，但由于SB Live MIDI In依赖的QPC时钟这时才走到59.95秒，SB Live MIDI In告诉Cakewalk这个音符是在59.95秒的时候弹下去的。于是Cakewalk老老实实把这个音符记录在比第二小节开头早0.05秒的地方。随着时间的流逝，两个时钟的差距越来越大，我们不关掉Cakewalk, 出去吃顿饭回来，又开始第二次录音， 同样在第二小节开头我们又弹了一个MIDI音符，假设这时候TGT时钟已经走到6000秒了，QPC才走到5995秒，Cakewalk会把这个音符记录在比第二小节开头早5秒的地方。

现在我们很容易看出问题的关键在于两个不严格同步的时钟。 Cakewalk记录MIDI音符时采用了SB Live MIDI In报告的时间，这个时间如果比Cakewalk自己的时钟快或慢，记录下来的音符就会延后或提前。有人可能已经想到了，让Cakewalk不听SB Live MIDI In报告的时间不就解决问题了？ 正是如此， Sonar从2.1开始有了一个选项IgnoreMidiInTimeStamps(在TTSSEQ.INI文件的[Options]下), 2.2版本以后这个选项默认是开启的，也就是说，不管SB Live MIDI In报告什么时间，Sonar根本不理睬，一收到MIDI信号就根据自己的时钟来记录。由于Sonar2.1以前的版本没有这个功能，如果老版本的Cakewalk(3.0, 9.0, Sonar1等等), 在你的电脑上出现了录制MIDI音符提前或延迟，基本上不可能通过软件设置来解决这个问题， 如果不想回到Win98, 勇敢升级到Sonar3吧。