[wdmaudiodev] Re: Writing an "unavoidable", "filter-like" audio driver
- From: Tim Roberts <timr@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Sun, 4 Oct 2020 12:08:07 -0700
On Oct 4, 2020, at 4:29 AM, learncyber (Redacted sender "learncyber" for DMARC)
I'm interested in writing a driver that will manipulate data coming from a
microphone, in a way that will affect every user-mode application accessing
it (for example, adding audio effects). Concretely, any user-mode app that
will try to access the microphone (i.e recording app, webcam app etc.) will
not be able to retrieve the original data, but only the data after
modification by the driver.
The driver should be implemented in a way that will "unavoidable" by the
applications, meanning applications will not be able to bypass it and gain
direct access to data coming from a microphone.
Can’t be done. One of the primary reasons behind the redesign of the Windows
audio system in Vista was that too many people had written “unavoidable” filter
drivers in order to “enhance” the user experience, and the net result was that
it became totally impossible for professional audio applications to get the
latency guarantees they needed in order to do real work. One fundamental
principle of the new design is that there will ALWAYS be an “exclusive” mode
that provides direct access to the audio hardware.
Now, to my (limited) unserstanding, the current windows audio pipeline design
is: microphone -> IHV driver -> Audio Engine -> application.
My question is, is it possible to interfere in the pipeline before the Audio
Engine? for example, attach a "filter-like" driver between the IHV driver and
the Audio Engine, or maybe between the microphone and the IHV driver?
No. The IHV driver is not involved in the data transfer. Today’s WaveRT audio
hardware has a circular buffer for data on the device. The driver maps that
circular buffer directly into the Audio Engine process at initialization time,
and then participates no more. The Audio Engine copies the data to and from
the hardware directly without involving a driver.
The audio subsystem does have the concept of “effects APOs” (audio processing
objects), which are filters that can sit in various places in the audio
processing graphs. However, those are not generic system-wide filters; the
APOs are considered part of the driver, and so have to be installed as part of
a driver package. And, as I mentioned above, an application can always request
“exclusive mode” to stream data without involving the APOs.
Put simply, what you’re asking is directly contrary to Microsoft’s philosophy
for the audio subsystem. Attempting to implement something contrary to
Microsoft’s philosophy is always going to lead to tears.
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
URL to WDMAUDIODEV page:
Other related posts: