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

  • From: "learncyber" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "learncyber" for DMARC)
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 06 Oct 2020 07:12:37 +0000

Thank you for the detailed answer, it raised a few more questions from my side:

"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?

"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 requests?

"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?
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?


Many thanks again.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 4 בOctober 2020 22:08, Tim Roberts <timr@xxxxxxxxx> wrote:

On Oct 4, 2020, at 4:29 AM, learncyber (Redacted sender "learncyber" for 
DMARC) dmarc-noreply@xxxxxxxxxxxxx wrote:

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.

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

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/


******************

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

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/

Other related posts: