Troubles creating virtual input device

The user and all related content has been deleted.

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.

1 Like

The user and all related content has been deleted.

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

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:

DRIVER_DISPATCH MyDeviceControl;

Does the compiler complain?

The user and all related content has been deleted.

The user and all related content has been deleted.

But again, I am streaming over UDP. Some packets will get lost.

Theoretically, yes. In practice, this almost never happens.

Now of course I can enumerate the packets and then for each lost packet, fill in zeros, but then I don’t have contiguous audio which will probably sound awful.

Yes, but since this would only occur in extraordinary circumstances, in my mind the risk is low.

What actually happens if I decide to modify the UpdatePosition function…

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.

1 Like

The user and all related content has been deleted.

I find it hard to believe that the Microsoft driver guys would publish a simple example that fails to target 20% of Windows machines

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

The user and all related content has been deleted.

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

1 Like

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.

1 Like

The user and all related content has been deleted.

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.