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/
