Hello, I could not understand how in a company with huge resources like Microsoft nobody notices big flaws in design concepts like the one I'm going to describe. MS WaveRT documentation explains the idea of improving streaming performance by eliminating driver code processing from the streaming path. I'll explain how actually it degrades performance by a very significant amount, and how it could not be otherwise. And also what should be the optimal approach. For the audio hardware, it's very easy to generate an interrupt every n samples or n time, it's the way the audio hardware notifies it needs more data. Ideally, the audio subsystem should provide methods to specify the frequency of the audio interrupt to allow adaptation to different latency requirements and overall system performance. In this scenario, a periodic interrupt is generated. The driver handles it, basically by notifying the event upstream, what normally will involve a kernel/user transition unless the whole streaming is done in kernel mode. Upon reception of such notification, the application writes data to the soundcard buffer. The idea of mapping the buffer the hardware is actually reading from to user memory so that this operation does not involve an additional user/kernel transition is great, and here is where WaveRT can actually improve performance. WaveRT also provides the idea of mapping the playback position to user memory to avoid more user/kernel transitions. Kudos again. But MS proposes to replace the audio driver interrupt based notification by a timer based polling of the playback position, and this is the big mistake. The intention is to remove the lasting kernel user transition. The problem is that ultimately, the timer is based in a hardware timer interrupt, so a kernel/user transition is unavoidable, they simply changed the source of the interrupt used to notify that more data is needed. Now let us see the difference between using the audio interrupt and the timer interrupt. If the audio interrupt is used, nothing more than passing the notification is necessary, and only one interrupt every n samples will occur, just as necessary. If the timer interrupt is used, the hardware timer period may be reduced to allow for the required resolution, and n timer interrupts can and will normally happen before each software timer notification (except if system timer period and sw timer period are the same). Every timer interrupt involves increasing timekeeping values and looking through tables of software timers, both kernel and user mode timers. One of these timers drives the process and thread scheduling. and finally another one is the one the application created to be notified, so that after n interrupts, the timer elapses and the notification must be passed to user mode, obviously causing the unavoidable kernel/user transition. Only that much more kernel processing, including multiplying the frequency of interrupts, is necessary than when directly using the audio hardware interrupt. The timer interrupt allows a program to choose the period and how much data will put behind the playback position. This is good. But can be best achieved by providing a way to pass to the audio hardware the desired interrupt period. There are other disadvantages of the general purpose timer. One is that we want a "realtime" timer, regardless of what "realtime" means in windows. I mean one that will preempt all lower priority stuff, always. It might be possible to map the audio interrupt user mode notification to a highest rt priority. By using timers based in the timer interrupt, we may end competing with Joe's application that request the highest priority for a smooth animation or things like that. Nobody should do that, but we know. Scheduling is another area in Windows which is very poorly designed, and MS always says "it was not intended to." as if doing it right would be more difficult or have any disadvantage over the grotesque and complex implementation chosen, but that's a very different story. At the end, the audio hardware interrupt is ultimately a timer interrupt perfectly suited to the task. Using software timers instead, ultimately based in the general purpose timer interrupt, does not bring any benefit at all, but many disadvantages. I hope it's clear enough that again we reinvented the wheel and made it square.