[wdmaudiodev] WaveRT model conceptual flaw

  • From: "Jose Catena" <jc1@xxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 3 Jun 2009 10:49:25 +0200

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.

 

Other related posts: