[wdmaudiodev] Re: WaveRT model conceptual flaw

  • From: "Jose Catena" <jc1@xxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Thu, 4 Jun 2009 00:59:31 +0200

Ø  However, I would argue that the empirical evidence stands as a pretty good 


I was not objecting the WaveRT architecture as a whole. I clearly stated 
where’s the performance gain: the audio buffer and playback position registers 
mapped to user memory allows streaming without any driver intervention and 
excellent control. This is perfect!. Kudos to who designed it. I agree WaveRT 
performs as a whole much better than previous architectures. I also agree that 
there are more benefits than just performance. I repeat, excluding the timer 
issue, everything is as good as I could think.

About what I wrote, I do have both empirical and theoretical evidence (the 
later already explained and expended below) and you are not offering anything 
regarding it, but twisting my words to justify your desired conclusion, or 
perhaps you answered before thinking about it.

Please focus: Timer Interrupt! I already said the rest is perfect! You are 
being defensive where there is no attack. Are you related to Microsoft? 


Ø  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.

No, I did not assume that, nor was I writing an essay, much less about thread 
scheduling, and that detail does not relate to the difference between timer and 
audio interrupts (if any, the impact of this will favor the audio interrupt 
anyway, see below). Of course that the scheduler must decide if a switch is 
necessary after every interrupt and almost always it does. But I don’t see at 
all how this might argue against anything I wrote. Being what’s equal for every 
interrupt (the scheduler must decide which task will run next), obviously the 
timer involves much more before that. Not to mention the multiplication of 
interrupts whenever interrupt timer period < software timer period, and the 
software timers list evaluation. There is no way the timer interrupt could be 

I can’t believe I’m explaining how interrupts are better than timer polling in 
a driver development forum, really. Are you serious? You are very wrong,  
please use your mind and not your heart, there is really no technical basis to 
support your position regarding this. 


But I’ll insist because I think it’s important to have this clear, and perhaps 
in a future occasion someone will not think he’s smarter than anyone else 
inventing the square wheel again in something that affects everyone else like 
the OS.

See it this way (and this time please ignore any simplification irrelevant to 
the difference between both, and see below for a little more detail):

A)     Audio interrupt (or any other except timer): This is an event itself. It 
wakes up any thread waiting for that event, and the one with highest rt 
priority if any is selected to run immediately.

B)      Timer interrupt: Increment main timer, process the list of software 
timers. Each timer elapsed becomes an event equivalent to A (the audio 
interrupt above, all the rest before and after specific to timer, and note this 
is in a loop). Update current task execution timers, check for task timeout, 
find next task to run. Note also that before a software timer elapses and 
becomes an event like in A, several interrupts evaluated it repeatedly whenever 
timer interrupt period < sw timer period.

The timer interrupt will always have more to do, and indeed a lot. Never less, 
no way. And the worst, most probably several times instead of one.

And for what? For nothing. There’s no reason to do it.


A different story, now that you speak about scheduling: I don’t think it’s 
totally unrelated since low latency audio streaming is critically affected by 
the scheduler, but perhaps we should move to private mail since this is not 
specific to WDM architecture. But let me just start here.

To try incite you to think a bit next time, not to be arrogant: RT scheduling 
is really my expertise area. I developed a couple of RT OS, one being widely 
used in mission critical applications, including spacecraft and mass 
transportation. So, do you think you also know about rt scheduling? Excellent! 
Tell me what do you think about this:




                for each task waiting for this event  {

Change Task status to “ready to run”

If (task priority is rt and > selected priority) selected_task = task


                return selected task



Interrupt other than timer


selected = current;

                Selected = Eval_rt_event()

                If selected != current

                                Switch to (selected)



Timer interrupt


                Selected = current

                Increment main timer

                For each software timer

                                If elapsed


                If selected != current

                                Switch to (selected)


                update task execution counters

                                if current task timed out

                                                if task is rt: change its 
priority to regular time shared and mark it as non rt compliant

                                                selected = find highest 
priority task

                                                switch to (selected)



Simplistic? Really? Well, it is not exhaustive, just a draft, but it works 
perfectly. Tell me what’s the problem if you find one. What happens if joe’s 
app sets highest rt priority for non rt processing? nothing: after its first 
elapsed time slice will be  marked as non rt compliant. Could be it faster, 
simpler, or safer? Well, tell me how. Even if Windows has improved this in a 
significant way, I can really help to make it much better. If you have any 
chance of it being considered by the appropriate people at MS, and the 
intention is to find possible improvements, I will be more than happy to share 
my knowledge. On the other side, if you are simply trying to argue in defense 
of  what has been done regardless of technical rigor, as seems to be the case, 
please don’t waste your and my time.


Ooops, too many lines here, sorry.



Jose Catena



Other related posts: