UMDF Software Audio Driver?

NTDEV
1

Hi there - I’m fairly new to the Wonderful World of driver development, so
please go easy on me :wink: I need a few pointers, at least to make sure I’m
reading the right documents!

I want to write a software audio driver to route main audio streams through
a 3D rendering engine. Actual access to audio hardware needs to go through
user space as I may be using ASIO - I think the most natural way to do this
is to have the driver be some kind of “bridge” talking to a separate
user-space process which will have a GUI and perform the actual heavy
lifting. I looked into doing this through DirectShow but it doesn’t appear
possible.

I can probably base what I’m doing on the MSVAD example in the WinDDK, but
I’m trying to be a good citizen and use the new UMDF/KMDF model. Does anyone
know if this is possible / sane to do with UMDF? I’m reading a book on it
now, but it’s not clear to me yet what interfaces I’ll eventually need to
satisfy to accept the audio stream.

One way or another, I’ll also need a bridge from the driver to the separate
user-space process. What do folk recommend for this? If I’m streaming 7.1
I’ll need a reasonable bandwidth… Shared memory? Sockets? Are these going
to be easy to use from MSVAD or UMDF etc?

Thanks,

–Richard

2

On Sun, Jun 21, 2009 at 12:14:19PM +0100, Richard Furse wrote:

I want to write a software audio driver to route main audio streams through
a 3D rendering engine. Actual access to audio hardware needs to go through
user space as I may be using ASIO - I think the most natural way to do this
is to have the driver be some kind of “bridge” talking to a separate
user-space process which will have a GUI and perform the actual heavy
lifting. I looked into doing this through DirectShow but it doesn’t appear
possible.

That depends on how broad you want this to be. If you are able to live
with handling only your own applications, then finding a way to intercept
things within your application is well worth the trouble. The audio
subsystem in Windows is complicated.

Are you trying to fit yourself in the middle of the existing audio
stream, so that the normal speakers still work? Or are you actually
trying to create a full fake audio device that will be seen as an
autio renderer? That changes the answer.

I can probably base what I’m doing on the MSVAD example in the WinDDK,

MSVAD gives you a virtual audio device, where applications can select
your device as their output device. That means their output no longer
goes to the speakers.

but I’m trying to be a good citizen and use the new UMDF/KMDF model.
Does anyone know if this is possible / sane to do with UMDF?

No, it can’t be done in UMDF. Audio drivers are kernel streaming drivers
or “port class” drivers. Technically you could use the "miniport"mode
of KMDF, but in my view it’s more trouble than it’s worth for now.

If you are trying to filter the output on its way to the normal speakers,
then you might be able to write an APO (audio processing object), which
is a COM DLL that lives in the special audio process. That’s way easier
than writing a driver.

One way or another, I’ll also need a bridge from the driver to the separate
user-space process. What do folk recommend for this? If I’m streaming 7.1
I’ll need a reasonable bandwidth… Shared memory? Sockets? Are these going
to be easy to use from MSVAD or UMDF etc?

I’m still not clear on where the output goes. You send it to some kind
of rendering process, and then what? To the screen? To another system?
To a piece of hardware?

Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

3

Aha. Thanks for this - I’ll put the book I was reading on WDF firmly on the
bookshelf for now… Can anyone recommend something clear to read on
miniport drivers etc so I can get my head around MSVAD properly?

More below…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@probo.com
Sent: 22 June 2009 06:41
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] UMDF Software Audio Driver?

On Sun, Jun 21, 2009 at 12:14:19PM +0100, Richard Furse wrote:
>
> I want to write a software audio driver to route main audio streams
> […]
That depends on how broad you want this to be. If you are
able to live with handling only your own applications, then
finding a way to intercept things within your application is
well worth the trouble. The audio subsystem in Windows is
complicated.

Sadly not - I want to be able to divert the audio coming out of other
applications, e.g. while watching a film or playing a CD in Media Player.

Are you trying to fit yourself in the middle of the existing
audio stream, so that the normal speakers still work? Or are
you actually trying to create a full fake audio device that
will be seen as an autio renderer? That changes the answer.

This is a full “fake” audio device. I’m reprocessing the audio and using it
to drive an irregular speaker rig using Ambisonics and some new stuff. I
have it working already using physical cables to get the audio into the
code, but obviously that’s somewhat less than ideal.

> I can probably base what I’m doing on the MSVAD example in
the WinDDK,

MSVAD gives you a virtual audio device, where applications
can select your device as their output device. That means
their output no longer goes to the speakers.

> but I’m trying to be a good citizen and use the new UMDF/KMDF model.
> Does anyone know if this is possible / sane to do with UMDF?

No, it can’t be done in UMDF. Audio drivers are kernel
streaming drivers or “port class” drivers. Technically you
could use the "miniport"mode of KMDF, but in my view it’s
more trouble than it’s worth for now.

Okay, thanks. I’d read several hundred pages of a WDF book and numerous web
pages without working that out :-/

Any recommendations on a relevant book would be very much appreciated!

If you are trying to filter the output on its way to the
normal speakers, then you might be able to write an APO
(audio processing object), which is a COM DLL that lives in
the special audio process. That’s way easier than writing a driver.

Sadly not…

> One way or another, I’ll also need a bridge from the driver to the
> separate user-space process. What do folk recommend for
this? If I’m
> streaming 7.1 I’ll need a reasonable bandwidth… Shared memory?
> Sockets? Are these going to be easy to use from MSVAD or UMDF etc?

I’m still not clear on where the output goes. You send it to
some kind of rendering process, and then what? To the
screen? To another system?
To a piece of hardware?

The output goes to a speaker array, just not a 5.1 array or suchlike… For
instance, I’m using a quite irregular arrangement of 15 speakers here at the
moment, roughly organised as an upper and lower circle, with a higher
density at the front. The “front left” channel from a DVD actually comes out
of a bunch of speakers to give a solid impression of a front left sound
image to the audience. The software uses DirectSound or ASIO to access the
hardware, ASIO in this case (I’m not aware of a way to drive 15 speakers
with DirectSound right now). I already have an OpenAL driver using this
stuff; this embeds all the relevant software in-process within a running
game rather than using a bridging approach, however this is pretty heavy
numerical code and probably exactly what you *shouldn’t* be running in the
kernel!

So I guess I need a fairly simple kernel driver based on MSVAD that bridges
the audio out using some internal protocol for this project, using shared
memory or sockets or …? Using floats and 7.1 running at 48kHz you’re
dealing with a latency-sensitive 1.5MB/s though, so bandwidth is relevant
and I’m not sure what would be best to use yet. Ideas appreciated :slight_smile:

–
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.

Thanks!

–Richard

4

Richard Furse wrote:

Aha. Thanks for this - I’ll put the book I was reading on WDF firmly on the
bookshelf for now… Can anyone recommend something clear to read on
miniport drivers etc so I can get my head around MSVAD properly?

I’m not aware of any books. The source code is useful, although dense.
There have been a lot of mailing list postings on this kind of topic –
creative Googling would be fruitful. There is also the “wdmaudiodev”
mailing list, which is an excellent resource for this kind of thing.
Several members of the Microsoft audio team hang out there.

This is a full “fake” audio device. I’m reprocessing the audio and using it
to drive an irregular speaker rig using Ambisonics and some new stuff. I
have it working already using physical cables to get the audio into the
code, but obviously that’s somewhat less than ideal.
…
The output goes to a speaker array, just not a 5.1 array or suchlike… For
instance, I’m using a quite irregular arrangement of 15 speakers here at the
moment, roughly organised as an upper and lower circle, with a higher
density at the front. The “front left” channel from a DVD actually comes out
of a bunch of speakers to give a solid impression of a front left sound
image to the audience. The software uses DirectSound or ASIO to access the
hardware, ASIO in this case (I’m not aware of a way to drive 15 speakers
with DirectSound right now). I already have an OpenAL driver using this
stuff; this embeds all the relevant software in-process within a running
game rather than using a bridging approach, however this is pretty heavy
numerical code and probably exactly what you *shouldn’t* be running in the
kernel!

So I guess I need a fairly simple kernel driver based on MSVAD that bridges
the audio out using some internal protocol for this project, using shared
memory or sockets or …? Using floats and 7.1 running at 48kHz you’re
dealing with a latency-sensitive 1.5MB/s though, so bandwidth is relevant
and I’m not sure what would be best to use yet. Ideas appreciated :slight_smile:

1.5MB/s is a trivial amount of data. Latency is a concern, but
bandwidth need not be.

Yes, it sounds like you need the full monty – a kernel audio device.
Before you embark on the development yourself, however, allow me to
*strongly* suggest that you investigate the Virtual Audio Cable:
http://software.muzychenko.net/eng/vac.html
This is a virtual audio device that several others have recommended over
the years. It allows you to route output data from the virtual device
into an application for manipulation. It may end out that you need
something more than this, but the time and money you would save if this
worked out should not be underestimated. It would be well worth your
time to spend a few days to find out whether this can do the job for you.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.