The simplest way to prevent render and capture devices from showing up is
to edit minipairs.h. If you scroll down to the bottom of that file, you
will find g_RenderEndpoints[] and g_CaptureEndpoints[]. Just comment out
the devices you do not need and they wont be instantiated. If you really
want to clean the code, then you could climb your way up starting from this
array and remove all the code that these miniport pointers point to.
On Mon, 28 Jan 2019 at 02:14, Nick Bauer <synchronizedobject@xxxxxxxxx>
wrote:
Tim,
Thank you for the response. The SYSVAD example from MS is definitely
something i've spent several hours mucking around with already. The
biggest issue i am facing right now is the inability to compile it for
x64. Please see this:
https://stackoverflow.com/questions/54393271/linker-error-when-compiling-windows-kernel-mode-driver-x64
.. I might just need to reinstall everything and get a clean config setup.
Note: when i remove all of the calls to RtlStringCbPrintfW, it will
compile, but i haven't figured out yet how to replace that call to get
around whatever linker issue i am having. Ideally, i could resolve the
linker issue.
I think i can probably use this framework to put my code in, however I
would also love to strip out all of the other pieces that are not relevant
to my project, as i only need the fake mic.
Any advice on how I might proceed is greatly appreciated.
Thanks,
Nick Bauer
On Sun, Jan 27, 2019 at 9:50 PM Tim Roberts <timr@xxxxxxxxx> wrote:
You have chosen a difficult place to start. Audio drivers are
complicated, and the environment in which they operate has some unique
issues.
In the early days of Windows, pre-Vista, many people wrote filter drivers
to do the cutesy things you’re talking about here. So many people wrote
cutesy, time-consuming filter drivers that it became impossible for
professional audio applications to get anything approaching the guaranteed
latencies that they need to do their thing. So, when the Audio Engine was
totally rewritten in Vista, the philosophy was changed. Audio drivers work
with the Audio Engine. For WaveRT drivers, which is almost all audio
drivers, the audio data is never touched by kernel code. The Audio Engine
reads and writes from circular buffers in the hardware directly. There’s
no place for a kernel filter to hook in.
Conceptually, what Microsoft wants you to do is write a Global Effects
Audio Processing Object (GFX APO), which is a user-mode DLL that runs
inside the Audio Engine process. There are 4 or 5 classes of FX APOs that
tap in at various points in the audio pipeline. However you can’t just
distribute a system-wide GFX APO, because that would lead to the same kind
of latency muck that we had before. Instead, an APO is considered part of
the hardware, and gets distributed and installed as part of the driver for
a given audio device. There are sample APOs in the massive SYSVAD driver
sample.
The architecture you’re proposing is certainly possible, but it’s a
difficult path. The SYSVAD sample I mentioned above implements a fake
microphone and a fake speaker. The fake microphone is fed from a signal
generator, the fake speaker writes to a WAV file. The SYSVAD driver is
close to what you want, but the Microsoft audio team has chosen to use it
as a platform to demonstrate essentially every feature that an audio driver
can support, so it is extremely large. You should take a look to see what
you’re facing:
https://github.com/Microsoft/Windows-driver-samples/tree/master/audio/sysvad
—
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/
