I am planning to write an application which intercepts data from microphone, processes it, then hands over to upper level clients. The application should present itself as a device so that if a user chooses to use it instead of standard audio input hardware, it starts doing its job. Target platforms are XP, 2003 and later.
I’m an experienced Windows/C++ programmer but completely new to device driver programming. Please point me to the right direction where I can get a quick start (sample code, articles, etc). Greatly appreciated.
I am planning to write an application which intercepts data from microphone, processes it, then hands over to upper level clients. The application should present itself as a device so that if a user chooses to use it instead of standard audio input hardware, it starts doing its job. Target platforms are XP, 2003 and later.
Be aware that Vista uses an entirely different design and philosophy for
its audio subsystem. It may actually be easier to start with Vista,
since you could write your filter as an LFX APO entirely in user mode.
You might ask your question on the wdmaudio mailing list, http://www.freelists.org/list/wdmaudiodev. The Microsoft audio team
hangs out there, and they are very responsive to questions.
I’m an experienced Windows/C++ programmer but completely new to device driver programming. Please point me to the right direction where I can get a quick start (sample code, articles, etc). Greatly appreciated.
What you ask is a surprisingly difficult and complicated task. If you
have a cooperative application, it’s not too bad; you can write a
DirectShow source filter that talks to the actual hardware device.
That’s a couple of weeks work, and I find DirectShow to be an
interesting and entertaining environment. (I have great admiration for
the designers of DirectShow; the package was designed some 12 years ago,
and it is still being used and extended today, with 98% of the code
completely unchanged.)
If you really want to offer yourself as an audio device to unaware
applications, that means you have to write a kernel driver. There are
at least three different models for kernel audio drivers, and the
criteria for choosing between them are not clear. You might take a look
as the Microsoft Virtual Audio Device in the DDK, in src\audio\msvad.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
My team developed such kind of driver using the AVStream model. There
are two samples available in the DDK which are both not very useful. We
used a two layer architecture: WDM bus driver and AVStream on top. So we
can enable/disable the audio device dynamically and also vary some
properties, e.g. supported sampling rates, channel count, etc.
I can tell that this is really not an easy task and definitely not a
project to start driver development with. If you are able/willing to
discuss about licensing an existing solution, contact me directly.
Best regards,
Udo Eberhardt
Tim Roberts wrote:
xxxxx@modernchineselearning.com wrote:
> I am planning to write an application which intercepts data from microphone, processes it, then hands over to upper level clients. The application should present itself as a device so that if a user chooses to use it instead of standard audio input hardware, it starts doing its job. Target platforms are XP, 2003 and later.
>
Be aware that Vista uses an entirely different design and philosophy for
its audio subsystem. It may actually be easier to start with Vista,
since you could write your filter as an LFX APO entirely in user mode.
You might ask your question on the wdmaudio mailing list, http://www.freelists.org/list/wdmaudiodev. The Microsoft audio team
hangs out there, and they are very responsive to questions.
> I’m an experienced Windows/C++ programmer but completely new to device driver programming. Please point me to the right direction where I can get a quick start (sample code, articles, etc). Greatly appreciated.
>
What you ask is a surprisingly difficult and complicated task. If you
have a cooperative application, it’s not too bad; you can write a
DirectShow source filter that talks to the actual hardware device.
That’s a couple of weeks work, and I find DirectShow to be an
interesting and entertaining environment. (I have great admiration for
the designers of DirectShow; the package was designed some 12 years ago,
and it is still being used and extended today, with 98% of the code
completely unchanged.)
If you really want to offer yourself as an audio device to unaware
applications, that means you have to write a kernel driver. There are
at least three different models for kernel audio drivers, and the
criteria for choosing between them are not clear. You might take a look
as the Microsoft Virtual Audio Device in the DDK, in src\audio\msvad.
Thanks for both replies. I’ve joined admaudiodev list.
Udo Eberhardt, I am certainly willing to look at the licensing option. The budget is limited though because I intend to write it as a shareware or freeware. Please contact me at mcl.services[at]gmail[dot]com, I don’t know how to get your email address.
There are several audio driver miniport models available. You should
take a look at AVStream and PortCls model. The StreamClass model is
out-dated and not recommended for new designs.
AVStream is the most flexible model as with this your miniport attaches
directly to the KS.SYS driver. MS uses this model (and recommends to use
it) for external sound cards on USB, 1394, etc. The problem with
AVStream is that there is no real-world example available. The DDK has
two samples avshws and avssamp which could be used as a starting point.
PortCls provides a better abstraction, so you have to write less code.
There are several subclasses such as WavePCI, WaveCyclic, WaveRT (Vista
only). These models are tailored for PCI sound cards or similar internal
sound cards such as HD audio. You can also create a virtual sound driver
using one of these models. The DDK/WDK includes samples and you will
find many people (e.g. on wdmaudiodev) using these models.
In any case you will need to create a private data path that provides
access to the ‘bottom edge’ of your virtual sound device. There are
several ways to accomplish this:
Create a private device object (if the miniport supports this).
Support read/write requests on this device object. In this case the
audio driver will be root-enumerated and loaded statically.
Load the audio driver on top of a WDM bus driver’s child and
communicate with the bus driver via IoCallDriver. Your user mode app
opens the FDO of the bus driver and sends read/write requests to it. In
this case the bus driver will be root-enumerated and loaded statically.
The bus driver provides further flexibility. You can add/remove your
virtual device instances dynamically.
We implemented our virtual audio device driver the latter way.
Thanks for both replies. I’ve joined admaudiodev list.
Udo Eberhardt, I am certainly willing to look at the licensing option. The budget is limited though because I intend to write it as a shareware or freeware. Please contact me at mcl.services[at]gmail[dot]com, I don’t know how to get your email address.
Tim, about different models of kernel audio driver, do you mean WaveCyclic, WavePci? What is the third one?
Udo, regarding the two ways you suggested (create private device object and load the driver on the top of a WDM bus driver), which one you think is easier for a beginner to start with? Advanced features are not required, such as dynamic add/remove devices.
Tim, about different models of kernel audio driver, do you mean WaveCyclic,
WavePci? What is the third one?
No, I meant stream class, portcls, and AVStream, as Udo suggested. Those
are driver models. WaveCycle and WavePci are both just examples of
portcls drivers.
It is not necessary to implement this as a kernel mode driver. At least on
win2k/winxp/2003 you could implement it as a user mode DLL which implements
waveInXXXX interfaces. However I am not sure if it works with Vista
Thanks,
Roman
ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:xxxxx@ntdev… >I am planning to write an application which intercepts data from >microphone, processes it, then hands over to upper level clients. The >application should present itself as a device so that if a user chooses to >use it instead of standard audio input hardware, it starts doing its job. >Target platforms are XP, 2003 and later. > > I’m an experienced Windows/C++ programmer but completely new to device > driver programming. Please point me to the right direction where I can get > a quick start (sample code, articles, etc). Greatly appreciated. > > TIA. >