[wdmaudiodev] Re: WHQL for virtual audio driver

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Tue, 3 Nov 2015 10:04:55 -0800

Matthew van Eerde wrote:



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” user-mode code?



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.)


People simply want to do system-wide audio effects processing, for
reasons that vary from silly to fascinating. As a consulting driver
writer, I have had 3 or 4 such requests in the last few years. Ideally,
they'd like to write an effects processor that can be slipped in to the
data stream just like an APO, at either the capture or render end, but
generically -- not associated with a specific piece of hardware.

Now, whether I agree with it or not, I do understand the justifications
that led to the tight coupling between GFX APOs and drivers, and that
coupling makes the APO path unworkable in the generic case. As a
fallback, the next design choice is to have a fake audio device to which
all of the applications can be routed. The fake device's audio stream
can then be routed to a user-mode service, where it can be massaged and
written to real speakers.

The WASAPI loopback interface lets me intercept the stream, but as far
as I know that's a read-only path -- there's no way for me to manipulate
it and spew it back out. I suppose if there were a "null" audio sink, I
could use the WASAPI loopback hooks on that, and redirect it to another
audio sink. Hmm, that option never occurred to me before.

--
Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

Other related posts: