[wdmaudiodev] Fwd: Can I eat the cake (Portcls.sys) and have it (DispatchDeviceControl) too?
- From: "Don Bell" <0dbell@xxxxxxxxx>
- To: wdmaudiodev@xxxxxxxxxxxxx
- Date: Sun, 8 Apr 2007 14:41:57 -0500
Guys, please ignore everything that I have written in my last two
messages. As I am delving into the subject, I discover major misconceptions
about approaching this task. I will post new questions (hopefully shorter
and clearer) instead of trying to present a complete solution based on my
ignorance.
I appologize for the premature posting of these two last messages (I was
simply in panic mode and so tried to gobble up too much for a short period
of time). I would appreciate your help to a newbie.
Don
---------- Forwarded message ----------
From: Don Bell <0dbell@xxxxxxxxx>
Date: Apr 7, 2007 10:32 PM
Subject: Fwd: Can I eat the cake (Portcls.sys) and have it
(DispatchDeviceControl) too?
To: wdmaudiodev@xxxxxxxxxxxxx
OK, got no response so far, but I am learning as I go... It seems that my
last question is answered by the documentation to
PcInitializeAdapterDriver(), which is called by MSVAD's DriverEntry():
"The *PcInitializeAdapterDriver* function loads pointers to handlers for the
following IRPs into the driver object:**
- IRP_MJ_CLOSE
- IRP_MJ_CREATE
- IRP_MJ_DEVICE_CONTROL
- ...
An adapter driver that overwrites one or more of the pointers above with a
pointer to its own IRP handler can call *PcDispatchIrp* from within its
handler routine in order to forward the IRP to PortCls. For a code example,
see the *sb16* sample audio driver in the Microsoft Windows Driver Kit
(WDK)."
So... it seems that my suspiction of using
driverObject->MajFunc[IRP_MJ_DEVICE_CONTROL] = IoctlHandler;
in DriverEntry() while ignoring the PortCls system was correct.
What I should do instead is add the above code *after* the call to
PcInitializeAdapterDriver() and in IoctlHandler() pass unhandled IRPs on to
the PortCls.
Now the only remaining question is whether CreateFile() from a user-mode
application would work on such driver (as described in my original
question)...
Thanks,
Don
---------- Forwarded message ----------
From: Don Bell < 0dbell@xxxxxxxxx>
Date: Apr 5, 2007 12:09 PM
Subject: Can I eat the cake (Portcls.sys) and have it
(DispatchDeviceControl) too?
To: wdmaudiodev@xxxxxxxxxxxxx
I wrote a virtual audio device driver, based on the MSVAD SIMPLE sample. It
basically does what the original sample does (saving 'play' output to a .wav
file), but now I would like to change that behavior to sending that output
to a USER mode process - which is not the same process that is using this
virtual audio device via the WaveOut/WaveIn interface...
So, the first question that comes to my mind, before wasting days to find
out that an audio device driver cannot communicate with more than one
process at a time, is: Can an audio device driver, based on MSVAD, be
"opened" by both a regular multimedia application (using either
WaveIn/WaveOut or DirectSound API) *and* an application that opens it via
CreateFile() and communicates with it via DeviceIoControl() ?
In other words, Can I take an MSVAD SIMPLE sample, add in its DriverEntry()
something like this:
driverObject->MajFunc[IRP_MJ_CREATE] = CreateHandler;
driverObject->MajFunc[IRP_MJ_CLOSE] = CloseHandler;
driverObject->MajFunc[IRP_MJ_DEVICE_CONTROL] = IoctlHandler;
And expect to get the communication between the audio driver and
the user-mode program (that opened the device driver via CreateFile()) to
work?
In my question, I am assuming of course that I implement CreateHandler(),
CloseHandler() and IoctlHandler() in the same way I implemented them when I
wrote "raw" WDM device driver (i.e. those that did not need to comply with
port/miniport scheme).
To better explain my question, I will try to describe the goal: Instead of
simply saving the audio output to a .wav file (as MSVAD does in
CMiniportWaveCyclicStreamMSVAD::CopyTo()), I would like to copy it to a
MAPPED memory buffer that is shared between the driver and a user-mode
process.
To the best of my understanding from Microsoft's white paper, "User-Mode
Interactions: Guidelines for Kernel-Mode Drivers", this is the recommended
way of sending data from the kernel-mode driver to the user-mode application
(and vice versa):
http://www.microsoft.com/whdc/driver/kernel/KM-UMGuide.mspx
The WDK documentation, on the other hand, suggests a method that - while it
is based on the same principle (IRP_MJ_DEVICE_CONTROL) - seems to require
following different protocol and rules. I am pretty confused here since I am
not totally sure that I understand the terminology.
http://msdn2.microsoft.com/en-us/library/ms794752.aspx
Any idea which approach or direction to take? Is there a sample out there
(or just a code snippet) that demonstrates that type of communication
between the driver with and a user-mode process while being used by another
application (via the DirectSound API)? The goal is to continue using the
MSVAD-based driver that I already wrote without resorting to a complete
re-write as a KS AVStream driver.
Many thanks in advance,
Don
Other related posts:
