[wdmaudiodev] Re: Starting to dev. a virtual Midi Port

  • From: Tim Roberts <timr@xxxxxxxxx>
  • To: "wdmaudiodev@xxxxxxxxxxxxx" <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 13 Jul 2012 16:27:49 -0700

Revan Foly wrote:
>
> So I see I have different approaches available. Even though my program
> doesn't transmit any sound just NoteOn/Off and CC data, latency is a
> very important issue, therefore I'd like to try the most performant
> method, i it is reasonable for me to try getting it to work. If I'm
> correct that would be the Kernel Streaming method which is also the
> newer method and can also be expected to work with windows 8?

I don't think you should spend very much time worrying about that until
you know you have a problem.  The tradeoffs are not as clean cut as you
would like.

The age of the technology is not a deciding factor.  The WINMM driver
model was introduced in Windows 3.1, 1992.  Kernel Streaming 1 was
introduced in Win98 in 1997 or so.  Both are very mature technologies.

Further, many (most?) MIDI applications use the midiIn/midiOut APIs to
transfer data.  In that case, the user-mode driver will have virtually
no overhead at all (it's a few dozen instructions), whereas there will
be an adapter and a user/kernel transition in order to get to kernel
streaming.


>     Are you saying you just ran mpu401.sys at a command line?
>
> Well I admit it was kinda foolish but from what I read in the WDK
> Documentation, all that was necessary to test the driver was to
> configure a remote computer and then select the correct debugger in
> visual Studio 2012 RC and press "start debugging" - so I thought just
> selecting local debugging mode would be a thing worth trying. Maybe
> VS2012 would handle everything by itself.

The VS2012 method of developing and testing drivers is brand-new.  I
haven't even tried that yet.  The rumor is that it IS just that easy,
but you'd still need an INF of some kind to make that work.


>
>     Every WDK sample includes one, and there is certainly
>     documentation for them.
>
> Well I think you said it before but I definitely can't find a prepared
> INF file in this sample:

You're correct, the mpu401 and fmsynth samples don't have INF files. 
The other audio samples do, so you may be able to strip the non-MIDI
parts out, but I'm waffling here because INF files are not easy under
the best of circumstances.


> So if in both cases the port that other programs can connect to via
> midiIn and midiOut are created by the "allready there part" of the
> driver, what exactly do I have to submit to the driver. just the link
> between my application and the driver?

An application does midiInOpen or midiOutOpen.  The multimedia subsystem
then goes out to probe what MIDI devices it has available.  It will look
for WINMM user-mode drivers, and it will look for kernel streaming audio
kernel drivers that support MIDI data.  The application usually just
asks for the first one, and doesn't particularly care what lives
underneath.  The application then calls other midiIn or midiOut APIs to
send empty or full packets.

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

Other related posts: