[wdmaudiodev] Re: WaveRT model conceptual flaw

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Wed, 03 Jun 2009 09:41:18 -0700

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.

Other related posts: