[wdmaudiodev] Re: Writing an "unavoidable", "filter-like" audio driver

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Tue, 6 Oct 2020 23:57:26 -0700

On Oct 6, 2020, at 12:12 AM, learncyber (Redacted sender "learncyber" for 
DMARC) <dmarc-noreply@xxxxxxxxxxxxx> wrote:

"One fundamental principle of the new design is that there will ALWAYS be an 
“exclusive” mode that provides direct access to the audio hardware":
So if an application is in "exclusive" mode, will it read directly from the 
hardware memory (hence will demand an implementation of hardware memory 
reading by the application), or the whole proccess is still ran through the 
Audio Engine?

Exclusive mode bypasses the Audio Engine.  The WASAPI DLL will read directly 
from the hardware buffers.

"The [IHV] driver maps that circular buffer directly into the Audio Engine 
process at initialization time":
Is it the IHV driver responsibility to implament this kind of mapping? Or is 
it done by some other proccess (say, the Audio Engine), and the IHV is 
passive until asked to perform the mapping to a specific location? In other 
words, say I am an IHV and I intent to provide a driver with the hardware I 
supply, should I implement a mapping mechanism in the driver (say, during 
installation of the driver), or implement a function that will "listen" to an 
incoming requests for mapping with a target location, and execute the 

The mechanism is specified by the Intel HDAudio specification, which is the 
basis for the WaveRT driver model.  The hardware must have a circular buffer, 
and must have registers to manage the pointers.  The IHV driver maps the 
hardware’s buffer and the registers into the Audio Engine.

"The Audio Engine copies the data to and from the hardware directly":
Assuming the Audio Engine has a memory buffer to copy data from the hardware 
to, will it be possible to access and modify the memory whilst in the buffer 
and before it is read by the application?

Only if you can get inside the Audio Engine.  It uses interprocess 
communication to transfer data between the mapped hardware buffer and the 
WASAPI interfaces in the user’s application.

I see some faulties in this plane, such as a race between modifing the data 
in the buffer and the application trying to access it. Will there be a way to 
do that and ensure a pipelined, latency-reasonable process?

I’m not sure what you mean by “modifying the data in the buffer”.  For 
microphone data, the hardware puts the data in the buffer, the Audio Engine 
passes it into any system APOs, and then it gets transferred to the application.

In the 15 years since it was introduced, the model has proven to be resilient 
and low latency.
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.


WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx


Other related posts: