Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Troubles creating virtual input device
![[Deleted User]](https://wc.vanillicon.com/v2/cb8e8e4c117ea107c2a2d34f1d668d2a.svg)
[Deleted User]
Posts: 0
in NTDEV
The user and all related content has been deleted.
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
| Internals & Software Drivers | 4-8 Dec 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
Comments
It's absolutely true that virtual audio drivers in Windows are a pain in the butt. I get big bucks for creating those.
The key thing you're missing is that ALL communication with kernel streaming drivers goes on via ioctls. When you intercepted the IRP_MJ_DEVICE_CONTROL handler, you interrupted that communication, thus causing the house of cards to collapse. The change you need to make is in your MyDeviceControl handler. If you receive a request that you don't recognize, you don't complete it. Instead, you do
return PcDispatchIrp( DeviceObject,irp );. That lets port class do its normal processing, as if you hadn't been there.The same thing applies to all requests that you intercept. If you don't want it, call
PcDispatchIrp. Don't just blindly complete it.Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
OK... so, you have a debugging task to do, right?
Set a breakpoint in MyDeviceControl. Single-step into the code, line by line.
If it doesn't MAKE it to MyDeviceControl, get the output from !analyze -v and post it here. Otherwise, your problem will be solved.
Peter
Peter Viscarola
OSR
@OSRDrivers
That's the right recipe. Are you using some wonky compiler options that are giving you the wrong linkage? If you add this before the function:
Does the compiler complain?
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Theoretically, yes. In practice, this almost never happens.
Yes, but since this would only occur in extraordinary circumstances, in my mind the risk is low.
So, do what an NTP server does, and tweak the byte count a little at a time until you catch up? In practice, this probably works fine. The HLK tests do some very precise throughput analysis and would probably be irritated by that, but the audio subsystem itself is prepared to handle devices whose clocks are a few Hertz off of normal.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
I mean this with no sarcasm or disrespect: But if you find it hard to believe that a current Windows driver sample doesn't work on Win7, you haven't been around much.
As, I think Mr. Roberts said here recently, in Redmond when it comes to drivers the only version of Windows that really exists is the one that is ABOUT to be released. Except for a few extraordinary folks in the WDK team, most MSFT folks don't really have time or interest to think about making drivers backward compatible to Win 7. Win 7 is dead to them. Witness the whole controversy of driver cross-signing on Windows 7.
Peter
Peter Viscarola
OSR
@OSRDrivers
Thanks for not taking offense, because none was intended.
First let me say that I know less than anybody on here about audio devices. But, just taking one of the system data structures that you're seeing as undefined (PCSTREAMRESOURCE_DESCRIPTOR), and looking in the WDK docs for info about that structure, I see this:
...which indicates this is a new structure with Windows 10.
So... yeah. No Win 7 support.
Peter
Peter Viscarola
OSR
@OSRDrivers
The "SimpleAudioSample" is brand new. Sysvad has the advantage of being derived from MSVAD, which has a lineage dating back to the 20th Century. Although it has new features, most of them are fairly well contained. "SimpleAudioSample" was created from scratch in the new world. The author made no attempts to make it backwards compatible.
The other direction is almost always easy. The MSVAD sample still works, and indeed that's what I use as the basis for the virtual audio drivers I create.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Hi, it seems I have a related problem.
I would like to use 32-bit floats as input data format to my audio driver.
I'm trying to replace KSDATAFORMAT_SUBTYPE_PCM with KSDATAFORMAT_SUBTYPE_IEEE_FLOAT for rendering but the playback device never shows up under "Audio inputs and outputs" in the device manager.
I have a working driver based on the sysvad example but when I change to KSDATAFORMAT_SUBTYPE_IEEE_FLOAT everywhere the playback device is not displayed anymore.
Seems that I've missed something.