内核dpc定时器
第一种方式是dpc定时器，这种方式是应用层主动拉流
KDPC channel0AudioDpc;
KTIMER channel0AudioTimer;
KeInitializeTimer(&devext->channel0AudioTimer); //初始化定时器对象
KeInitializeDpc( &devext->channel0AudioDpc, channel0AudioDpcRoutine, devext );//初始化dpc对象，注意最后一个参数就是channel0AudioDpcRoutine中的第二个参数。
NTSTATUS DispatchProcess (IN PKSPIN pin)
{
PDEVICE_EXTENSION devext = (PDEVICE_EXTENSION)(KsPinGetDevice(pin)->Context);
LARGE_INTEGER largetime;
largetime.QuadPart=-10 * 1000 *2; //number of 100 ns intervals ,so here is 2ms
KeSetTimer(&devext->channel0AudioTimer,largetime,&devext->channel0AudioDpc);
//开始DPC定时器，3个参数，第一个参数是KTIMER对象，第二个参数是时间间隔，第三个参数是dpc对象
return STATUS_PENDING;
}
//dpc 函数
void channel0AudioDpcRoutine(struct _KDPC* p_dpc,PVOID context,PVOID arg1,PVOID arg2)
eg: void OnDPCTimer(IN PKDPC pDPC,
IN PVOID pContext,//这就是KeInitializeDpc传入的参数
IN PVOID SysArg1,
IN PVOID SysArg2)
在需要停止的地方调用KeCancleTimer来取消定时器
第二种方式，中断函数中有中断到来时把它入队dpc，驱动往上推流
有中断时：KeInsertQueueDpc(&devext->channel0AudioDpc,NULL,NULL);
NTSTATUS DispatchProcess (IN PKSPIN pin)
{
return STATUS_PENDING; //此处直接返回，在dpc处理函数里向应用层写入。
}
第二种方法只能正确处理48Ｋ的声音：
总数据量：48000*2*2＝192000，应用程序每次请求1920个字节，驱动中的CELL刚好也是1920，这样就每一个中断往应用层写入一次，每秒刚好有100个中断（192000/1920）。
这个时候两种方法的效果是一样的，第二种方法又不依赖系统的时钟分辨率（win10 64位中setTimer有15ms的误差）。所以处理48Ｋ的声音没有问题。
当源是44.1Ｋ时，44100*2*2＝176400， 176400/1920＝91.875
应用程序每次只请求1764个字节，每一个中断对应有1920个字节，这样每一个中断就会在驱动中累积156个字节而导致数据在驱动中溢出。解决这个问题只能更改驱动中的CELL刚好也是1764，但是它不是128的倍数又不满足fpga的要求。所以处理44.1Ｋ的声音是个问题。
第一种方法拉数据依赖应用程序的请求，不对应中断的个数去一对一的送数据就没这个限制。
另外，应用程序每次取声音的数据量是根据系统的声音设置而定的，系统声音设置“录制”属性中设置44100每次取1764，设置48000每次取1920。默认值是第一次安装驱动中的接口而定的。使用过程中如果信号源有改变，系统声音设置没办法同步更改，这样就会导致播放声音不正常。所以声音这一块驱动中要把44.1转为48最好，最好只有一种48Ｋ输出。