再看《深入理解windows》的时候，书中提到windows并非总是一个实时系统。主要原因是由于系统本身的设计，以及驱动，应用软件各方面一同构成的；然后就偶然了解到RTX这个辅助工具。
看了一下RTX的介绍，实际上RTX就是一个和windows内核相仿的一个系统。然后RTX会工作在一个或者几个独立的vcpu/cpu上，使得该vcpu/cpu变成一个实时系统。进而进行部分接管windows的一些中断响应、驱动操作。
然后就看到这个RTX的关于如何配置的视频时，听到对方介绍到用到RTX和没有用到RTX的系统。在用到了RTX的windows里面，对于一个1us采样的5s beep音频来说，能够流畅的播放出来。而对于一个没有使用RTX的是系统来说，就会出现断断续续的问题。
接着因为感兴趣对方是如何测试，就随手写了一段代码：
#include "stdafx.h"
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
for (int i =0; i<5000; ++i)
{
DWORD dwstart = GetTickCount();
Beep(750, 60);
DWORD dwend = GetTickCount();
printf("now cur %d, cost time %d\n", i, dwend - dwstart);
}
Sleep(1000*3600);
return 0;
}
由于gettickcount本身也是个严重不准的时间函数，所以也只能间接看一看；且整个声音均为断断续续。
通过测试发现，每个循环周期都有可能不是稳定的，有时候会存在2-5ms的误差，也或许和gettickcount的分辨率有关，或许确实和beep函数有关。
后来通过代码修改为如下，整个音频则变为流畅：
#include "stdafx.h"
#include <Windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
Beep(750, 5000);
Sleep(1000*3600);
return 0;
}
通过上述观察然后跟踪了一下beep的汇编，汇编代码如下：
在msdn在NtDeviceIoControlFile中的描述：
参考beep函数的说明以后，在通过上述的描述；可见每调用一次beep始终是等待硬件处理完成以后，才会返回beep。然后又因为windows为非实时系统，所以就会出现上诉的代码1会出现发声会出现断断续续的问题。因为各种中断什么时候能够被处理，或者处理结束都是没有很强的约束性的。
当然，sleepex本身也是一个要走软中断的模块，显然也会影响到代码的发声情况。至于sleepex的精度情况，我自己没找到msdn官方说明，但参考waitforsingleobject和sleep，那sleepex精度也不会很高。
