[wdmaudiodev] Re: Driver model for multi-client MIDI

  • From: Matthew van Eerde <Matthew.van.Eerde@xxxxxxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 17 Apr 2015 01:35:57 +0000

Actually, that API is single-client.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Cheng-mean Liu (SOCCER)
Sent: Thursday, April 16, 2015 6:23 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: Driver model for multi-client MIDI

Chen this out: with the API below, multi-client feature was supported at level
high than the driver.

From: wdmaudiodev-bounce@xxxxxxxxxxxxx<mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx>
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Andrew Vogan
Sent: Thursday, April 16, 2015 5:21 PM
To: wdmaudiodev@xxxxxxxxxxxxx<mailto:wdmaudiodev@xxxxxxxxxxxxx>
Subject: [wdmaudiodev] Driver model for multi-client MIDI

I am developing a multi-client kernel MIDI driver for a simple USB MIDI device
with a single port and bi directional traffic. By multi-client, I mean that
more than one application should be able to open the MIDI device, send messages
to the device, and receive messages (effectively broadcast) from the device.

My customer's device is a relatively simple USB Audio MIDI Class compliant
device. No software synth, just message traffic.


1. Do I have to write an AVStream driver to replace USBAudio.sys, which seems
like a lot of work, or can I get away with a miniport Port Class driver? To
put it another way, where does the single-client restriction in the Microsoft
native MIDI driver stack(s) originate from?

2. Any other "gotchas" to be aware of with a multi-client MIDI driver? Keeping
latency down will be important, so that's something I'll be paying attention to
as well.


Other related posts: