[wdmaudiodev] Re: Interacting with MSVAD through IOCTL

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Tue, 7 May 2019 14:26:47 -0700

plznospam@xxxxxxxxx wrote:


Have bi-directional stream exchange between the raw operating system audio and JACK (jackaudio.org).
In other words, the audio samples rendered through Windows should be available in a user-space application instead of being sent to a DAC, and the samples recorded from the microphone should be read from user-space memory instead of from an ADC.

Based on the contacts I've had, this is a very, very common desire.  It's kind of unfortunate that there is no simple sample that demonstrates this ability, other than the very, very complicated SYSVAD and the only slightly less complicated MSVAD.


Since JACK (a really potent audio framework) is used, it would be beneficial to have very little latency between both systems.
My initial approach is thus to modify the SaveData part of MSVAD and share a fixed-size buffer between the driver and the JACK user-space application.
Now from most research it seems that this ultimately will require IOCTL structures to break the boundary between kernel and user space (in a way that is regarded as sane and not a massive security hole).

As long as you're using ioctls, you can skip the shared memory thing and use ioctls to copy data into and out of circular buffers in the driver.  I've done several MSVAD-derivatives that way.


I combined both of these resources with the MS samples about IOCTL (github.com/microsoft/Windows-driver-samples/blob/master/general/ioctl/wdm/sys/sioctl.c) and ended up with most of the required boilerplate for the driver (which is at the very bottom). But it fails. Installing the driver is no problem as is evident by the kernel debug traces. As soon as an application tries to create a handle to the driver with CreateFile() or as soon as you manually inspect its properties with WinObj, you get a fatal system error (STATUS_ACCESS_VIOLATION):

I suspect the problem here is that you have removed way too much.  You have removed everything out of StartDevice, but there's stuff in there that is required.  You've removed the calls to InstallSubdevice, which calls PcNewPort, PcNewMiniport, and PcRegisterSubdevice,  Without those calls, when the Port Class driver gets a create request, it doesn't have any subdevices to which to pass it.

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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Other related posts:

  1. Home
  2. wdmaudiodev
  3. Archive
  4. 05-2019