I wasn’t sure whether Arthur meant “application”, “audio precision” (as a
colleague of mine suggested), or “access point” (e.g., perhaps the driver
functions as a Miracast receiver.) I’m still not sure, but like you I am
leaning toward “application”.
Arthur, can you confirm?
Tim, when you say a “pipe to user mode”, do you have in mind:
1. an audio playback endpoint that can be used by a dumb app (like
Virtual Audio Cable does it), or
2. a custom interface which the driver would expose to “in the know”
The closest thing to audio routing that Windows supports today is the WASAPI
audio loopback interface. In principle a driver could be packaged with a
user-mode service which includes a WASAPI loopback client; this could deliver
the audio back to the driver via a custom mechanism, and the driver could do
whatever it liked with it (e.g., deliver it up on a recording endpoint.)
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Roberts
Sent: Tuesday, November 3, 2015 9:40 AM
Subject: [wdmaudiodev] Re: WHQL for virtual audio driver
Matthew van Eerde wrote:
OK, so this is an audio recording scenario.
You know, this is one of the more frequently requested scenarios in the audio
driver world. Has the Microsoft audio team given any thought to releasing a
simple skeleton virtual audio driver sample with a pipe to user mode? For
years we've had MSVAD, but that's a 20,000-line behemoth demonstrating a
thousand esoteric features that aren't germane to the simple non-hardware case.
And it was never obvious to the casual observer that CopyFrom and CopyTo were
the magic locations for tapping the audio streams. Now, we have SysVad, which
is even more complicated, and so far I haven't found where the magic tap
That is - what is an “AP?”
That, in some parts of the world, is the accepted abbreviation for
Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.