[wdmaudiodev] identifying MIDI inputs and outputs

From: Pete Gontier <pete@xxxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Date: Wed, 01 Feb 2006 12:35:51 -0800
I¹m trying to identify the hardware underlying MIDI inputs and outputs. I¹ve
tried two strategies. Neither has worked. I'm not aware of others.


First strategy
--------------

Obtain the device interface pathname by means of passing
DRV_QUERYDEVICEINTERFACE to midiOutMessage or midiInMessage to obtain a
device interface pathname, and then passing SPDRP_HARDWAREID to
SetupDiGetDevideRegistryProperty. (I¹ve omitted some of the steps from this
description for the sake of brevity.) This works for inputs but not for
outputs. midiOutMessage claims success but produces a pathname referring to
the wrong device (a motherboard output¹s pathname refers to a USB device).
The cause of this problem is likely one of:

    -- midiOutMessage does not properly handle DRV_QUERYDEVICEINTERFACE
    -- the driver for my motherboard audio is broken
    -- my system is corrupt

The only possibility I¹m in a position to eliminate is the third, so I
reinstalled the system from scratch. The problem persisted, which means one
of the other possibilities must be true. Since I have no control over either
of them, I abandoned this approach entirely. (Even if I could establish the
fault lies with the motherboard driver, I must assume that other people have
the driver installed, and I would prefer my code work on those systems.)

Any insight?


Second strategy
---------------

MIDIINCAPS2 and MIDIOUTCAPS2 contain GUID fields (manufacturer, product,
component) intended to indicate the sort of information I need. They're not
supported by every driver, and when I call midiInGetDevCaps or
midiOutGetDevCaps for a driver which does not support these GUID fields, the
fields remain uninitialized. Fine. The callers of midiInGetDevCaps and
midiOutGetDevCaps can set those fields to GUID_NULL before making the call
so they can tell when they've received useful information.

It happens that the driver I care about does not support these GUID fields,
but it also happens I can bend this driver to my will, so I added support
for these fields to that driver. The support amounts to providing the
address of an instance of KSCOMPONENTID, but of course that still leaves the
issue of how to set the GUID values. If in the driver I set all the GUID
values to GUID_NULL, the values come through to callers of midiInGetDevCaps
and midiOutGetDevCaps just fine. However, if in the driver I set the GUID
values to anything else, they come through as garbage. Curiously, I seem to
get the same garbage GUID values in different fields of KSCOMPONENTID after
different invocations of midiInGetDevCaps and midiOutGetDevCaps.

The driver I care about is also an audio driver, so just as a sanity check I
passed an instance of MIXERCAPS2 to mixerGetDevCaps, and the GUID fields,
which in the driver are based on the very same instance of KSCOMPONENTID,
come through just fine.

I don't think the problem is in the driver.

Any insight?


Third strategy
--------------

I would love to hear that there is some other approach which will allow me
to identify the hardware underlying MIDI inputs and outputs. I only need a
positive ID because I care about one device only, so methods which cannot
identify some devices may be acceptable. What's not acceptable is using the
szPname field of MIDIINCAPS and/or MIDIOUTCAPS. That's definitely the wrong
way to go about doing this. Any other insight would be appreciated.


                                   -- Pete Gontier <http://www.m-audio.com/>



******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.com/
[wdmaudiodev] identifying MIDI inputs and outputs

Other related posts:
