Jose Catena wrote: > > > 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. > > ... > > 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. > > .... > > 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. > You clearly took a lot of time to write up this essay objecting to the WaveRT architecture. However, I would argue that the empirical evidence stands as a pretty good counterargument. That is, virtually every new computer that has shipped with Vista has included an HDAudio device, and hence a WaveRT driver, and the user experiences with audio performance have been very positive. To a certain extent, it doesn't matter whether an interrupt comes from a timer or from an audio device. Your essay assumes that only a timer interrupt will trigger scheduling, and that an audio interrupt goes straight to audio and then back again. That's not correct. The operating system goes through basic scheduling at every interrupt, timer or not. It always has to evaluate which is the next high-priority thread. There's more to a good user experience than raw cycles. In my view, the biggest benefit of the WaveRT driver model is that it enables the audio vendors to write much less kernel code. Many of the commodity audio device vendors have done a sucky job of writing drivers, so every feature that reduces the amount of code they have to write is a big net gain in both performance and reliability. If that feature costs 1% or 2% in CPU performance, it is a price well worth paying. -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.