Virtual Audio Driver (Reformatting)
m0rf
Control Panel etc as an ordinary multichannel driver with support for 5.1
etc. The actual driver implementation will use an existing codebase to
reformat the audio stream for a potentially complex non-standard speaker
layout and then pass the audio to an "real" underlying driver using
DirectSound or Steinberg ASIO.
I'm new to Windows driver development; DirectShow is the nearest I've got
historically. I'd really appreciate a few pointers on where to start with
this - can I link my existing libraries and their DirectSound/ASIO interfaces
into code based on the MSVAD audio samples for instance? I'm not very clear
on whether or not WDM audio drivers are user-space or not and what
constraints there are on what can and cannot be done. I've noticed that the
MSVAD sample code seems to say PAGED_CODE() all over the place, which makes
me think I might not be in my normal development context. I'm happy enough
reading documentation; there's just an awful lot of it so it would be really
useful to know which bits I should be focussing on.
Any pointers much appreciated - thanks!
Tim Roberts
>
>Hi there - I'd like to write a virtual audio driver that appears in Windows
>Control Panel etc as an ordinary multichannel driver with support for 5.1
>etc. The actual driver implementation will use an existing codebase to
>reformat the audio stream for a potentially complex non-standard speaker
>layout and then pass the audio to an "real" underlying driver using
>DirectSound or Steinberg ASIO.
Are you targeting Vista? Vista has sophisticated support for speaker
arrays, and the LFX/GFX APO mechanism lets you manipulate the output
stream, all with a user-mode DLL.
>I'm new to Windows driver development; DirectShow is the nearest I've got
>historically. I'd really appreciate a few pointers on where to start with
>this - can I link my existing libraries and their DirectSound/ASIO interfaces
>into code based on the MSVAD audio samples for instance? I'm not very clear
>on whether or not WDM audio drivers are user-space or not and what
>constraints there are on what can and cannot be done.
AVStream audio drivers are kernel drivers. The APIs are completely
different. You can't link to any code that needs any user-mode APIs. It
is possible to write a processing library that can be used in both
environments, but it's tricky.
You might be able to solve your problem using a WDM filter driver, if you
can target a particular piece of hardware for your experiments.
>I've noticed that the
>MSVAD sample code seems to say PAGED_CODE() all over the place, which makes
>me think I might not be in my normal development context. I'm happy enough
>reading documentation; there's just an awful lot of it so it would be really
>useful to know which bits I should be focussing on.
If you really, really feel the need to do this in kernel mode, then the
MSVAD sample will point you to the basics, but audio drivers are much more
complicated than most people believe. You might also ask this question on
the wdmaudiodev mailing list:
http://www.freelists.org/list/wdmaudiodev
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
m0rf
> m0rf <m0...@discussions.microsoft.com> wrote:
> >
> >Hi there - I'd like to write a virtual audio driver that appears in Windows
> >Control Panel etc as an ordinary multichannel driver with support for 5.1
> >etc. The actual driver implementation will use an existing codebase to
> >reformat the audio stream for a potentially complex non-standard speaker
> >layout and then pass the audio to an "real" underlying driver using
> >DirectSound or Steinberg ASIO.
>
> Are you targeting Vista? Vista has sophisticated support for speaker
> arrays, and the LFX/GFX APO mechanism lets you manipulate the output
> stream, all with a user-mode DLL.
Not specifically - I want the code to work on XP too.
Actually most of the stuff I'm doing is research about how to drive
complicated arrays of speakers and I don't WANT Windows to get too involved -
and if I'm talking to the speakers over ASIO it won't know what's going on
anyway!
> >I'm new to Windows driver development; DirectShow is the nearest I've got
> >historically. I'd really appreciate a few pointers on where to start with
> >this - can I link my existing libraries and their DirectSound/ASIO interfaces
> >into code based on the MSVAD audio samples for instance? I'm not very clear
> >on whether or not WDM audio drivers are user-space or not and what
> >constraints there are on what can and cannot be done.
>
> AVStream audio drivers are kernel drivers. The APIs are completely
> different. You can't link to any code that needs any user-mode APIs. It
> is possible to write a processing library that can be used in both
> environments, but it's tricky.
Okay. Sounds like I can't use AVStream in a simple way then.
> You might be able to solve your problem using a WDM filter driver, if you
> can target a particular piece of hardware for your experiments.
Hmm, that's an idea but doesn't really cover some important cases (e.g. when
using ASIO).
> >I've noticed that the
> >MSVAD sample code seems to say PAGED_CODE() all over the place, which makes
> >me think I might not be in my normal development context. I'm happy enough
> >reading documentation; there's just an awful lot of it so it would be really
> >useful to know which bits I should be focussing on.
>
> If you really, really feel the need to do this in kernel mode, then the
> MSVAD sample will point you to the basics, but audio drivers are much more
> complicated than most people believe. You might also ask this question on
> the wdmaudiodev mailing list:
Kernel mode sounds like a very bad idea.
Unless I could bootstrap across somehow? Perhaps I could write a kernel
driver that does little more than shove the audio stream into shared memory
somewhere to be picked up by a service. Or something. Would be a bit horrid,
but might work.
> http://www.freelists.org/list/wdmaudiodev
Thanks. Before I wander over there, can anyone confirm that I'm working with
correct assumptions:
1) There is more than one way to implement an audio driver, including
AVStream and WDM at least (any others?).
2) All of these alternatives have to be written in kernel space.
3) There's no way my existing application-style code will run here.
If so, I reckon I'm looking at some kind of hack to stream the audio back
from a kernel driver of some kind into user space. :-( Any suggestions?
> --
> Tim Roberts, ti...@probo.com
> Providenza & Boekelheide, Inc.
>
Thanks!
Tim Roberts
>
>Thanks. Before I wander over there, can anyone confirm that I'm working with
>correct assumptions:
>1) There is more than one way to implement an audio driver, including
>AVStream and WDM at least (any others?).
Well, AVStream drivers are WDM, but yes, there are several audio driver
models. Port class, stream class, and AVStream, for example. For
applications that use DirectShow, you can write a user-mode source filter
that is indistinguishable from an audio device. Maxim would remind us that
it's also possible to write an old-style waveIn driver in user mode.
>2) All of these alternatives have to be written in kernel space.
Except for a DirectShow source or a waveIn driver.
>3) There's no way my existing application-style code will run here.
*IF* your application code relies heavily on user-mode APIs, then no, it
won't run in the kernel.
>If so, I reckon I'm looking at some kind of hack to stream the audio back
>from a kernel driver of some kind into user space. :-( Any suggestions?
That's a synchronization nightmare.
m0rf
> m0rf <m0...@discussions.microsoft.com> wrote:
> >
> >Thanks. Before I wander over there, can anyone confirm that I'm working with
> >correct assumptions:
> >1) There is more than one way to implement an audio driver, including
> >AVStream and WDM at least (any others?).
>
> Well, AVStream drivers are WDM, but yes, there are several audio driver
> models. Port class, stream class, and AVStream, for example. For
> applications that use DirectShow, you can write a user-mode source filter
> that is indistinguishable from an audio device. Maxim would remind us that
> it's also possible to write an old-style waveIn driver in user mode.
>
> >2) All of these alternatives have to be written in kernel space.
>
> Except for a DirectShow source or a waveIn driver.
Okay... I've written a DirectShow filter already doing this kind of thing
for a different format, but it didn't seem to be used by Windows Media Player
when attempting to play 5.1 from DVDs. I just assumed that Media Player went
direct to the device for DVD playback. I'd be very happy to be proved wrong
here...
I've not looked at waveIn because I'd assumed it was stereo only. My
priorities are to get 5.1 and 7.1 into my code for rendering.
> >3) There's no way my existing application-style code will run here.
>
> *IF* your application code relies heavily on user-mode APIs, then no, it
> won't run in the kernel.
Sadly, yes.
> >If so, I reckon I'm looking at some kind of hack to stream the audio back
> >from a kernel driver of some kind into user space. :-( Any suggestions?
>
> That's a synchronization nightmare.
Yep. Which I'm still vaguely hoping to avoid - at least this approach is
POSSIBLE...
> --
> Tim Roberts, ti...@probo.com
> Providenza & Boekelheide, Inc.
>
Thanks again!
Tim Roberts
>
>Okay... I've written a DirectShow filter already doing this kind of thing
>for a different format, but it didn't seem to be used by Windows Media Player
>when attempting to play 5.1 from DVDs. I just assumed that Media Player went
>direct to the device for DVD playback. I'd be very happy to be proved wrong
>here...
As long as Windows Media Player used a DirectShow graph for playing DVDs,
you should be able to get it to substitute a different renderer. By
default, it picks the default DirectSound renderer, but if you get your
renderer in there with a better Merit value, you should be chose.
>I've not looked at waveIn because I'd assumed it was stereo only. My
>priorities are to get 5.1 and 7.1 into my code for rendering.
I don't know this. You may be right.