[wdmaudiodev] Re: sAPO must be real-time compatible

  • From: "Andrew Sha......" <universalkludge@xxxxxxxxxxx>
  • To: wdmaudiodev wdmaudiodev <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 9 Jul 2010 18:34:45 -0500

Yes, it is based on the assumption that the driver completes requests 
synchronously, so the ERROR_IO_PENDING means that a filter got introduced 
screwing the picture
I guess it is not such a good idea just to return from an ADOProcess call when 
some encoding supposed to be done, is it?
But it is a good idea to return processed results of a previous ADOProcess 
call, submitting data of the current ADOProcess call to the driver, the only 
question is how to handle the very first call. Any bright ideas?

Date: Fri, 9 Jul 2010 16:20:37 -0700
From: timr@xxxxxxxxx
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: sAPO must be real-time compatible

Andrew Sha...... wrote: 

It looks like DeviceIoControl w/ overlapped I/O + 
GetOverlappedResult(..bWait=FALSE)  is the way to go and upon 
ERROR_IO_INCOMPLETE returned just fail processing 
ERROR_IO_PENDING is that one that means "the driver is still working on this".

Your behavior depends on what you need.  If you are confident that your driver 
will always complete requests immediately, then that might be an OK plan.  But 
in other cases, you might just leave the request running and return so the 
audio graph continues to run.  At some later point (in a separate thread maybe, 
or just at the next data packet), you can check to see if your outstanding I/O 
has completed yet.

There are lots of ways to handle it.  The key is that the audio engine is a 
real-time process, and if you block it, audio will suffer.
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with 

Other related posts: