[wdmaudiodev] Audio miniport driver

  • From: wdmaudiodev@xxxxxxxxxxxxxx
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Wed, 21 Oct 2020 08:42:59 -0700

Hi folks,

I'm working on an audio pass-through miniport driver, and I got a suggestion from Matthew van Eerde about only exposing the capture endpoint, and having our app use a custom device interface to send audio data to the driver.

Many of the Microsoft driver samples create a custom device interface, and include a user-mode client that exercises it, and osr.com had some good articles on custom interfaces and symbolic links.

Though many of the examples were kernel mode drivers, unfortunately none of them were miniport drivers, and it's not clear to me what adjustments I need to make. I tried just repeating the pattern in the examples; creating the device interface, creating a symbolic link, creating a queue, and registering *EvtIoWrite* & *EvtIoDeviceControl* callbacks:


// Error-checking removed for brevity...
NTSTATUS StartDeviceCallback(DEVICE_OBJECT *pDeviceObject, IRP *pIrp, IResourceList *pIResourceList)
{
    // Get a handle to the framework device object associated with the specified WDM physical device object
*    WDFDEVICE hWdfDevice = WdfWdmDeviceGetWdfDeviceHandle(pDeviceObject);**
*
    // Tell the Framework that this device will need an additional interface
    ntStatus = WdfDeviceCreateDeviceInterface(hWdfDevice, &GUID_DEVINTERFACE_IMMERSED_AUDIO, nullptr);

    // Make the PDO easily accessible by name to user-mode applications by explicitly creates a symbolic link for this device.
    DECLARE_CONST_UNICODE_STRING(userDeviceName, L"\\DosDevices\\MyAudioDevice");
    ntStatus = WdfDeviceCreateSymbolicLink(hWdfDevice, &userDeviceName);

    WDF_IO_QUEUE_CONFIG queueConfig;
WDF_IO_QUEUE_CONFIG_INIT_DEFAULT_QUEUE(&queueConfig, WdfIoQueueDispatchParallel);

    queueConfig.EvtIoWrite = EvtIoWriteCallback;
    queueConfig.EvtIoDeviceControl = EvtIoDeviceControlCallback;

    WDFQUEUE queue;
    ntStatus = WdfIoQueueCreate(hWdfDevice, &queueConfig, WDF_NO_OBJECT_ATTRIBUTES, &queue);

...but the system bugchecks on the initial *WdfWdmDeviceGetWdfDeviceHandle(DeviceObject)* call (/Fatal System Error: 0x0000007e/). Whether I did this in my AddDevice or StartDevice callback made no difference.

I like Matthew's suggestion, because it eliminates exposing the render endpoint (which should only be used by our app) to end users.

Can anyone shed light on how to add a Custom Device Interface to an (audio) miniport driver?


Thanks.



Other related posts: