Share via

MIDI Driver Test

  • Article

Note  This content applies to the Windows Logo Kit (WLK). For the latest information using the new Windows Hardware Certification Kit (HCK), see Windows HCK User's Guide on the Windows Hardware Dev Center.

Type: Automated Test

Overview

The MIDI Driver Test (MIDDRV32) ensures that an audio device complies with the Multimedia SDK documentation that is related to the MIDI family of multimedia APIs.

Details

This test requires that an audio device and driver are installed in a test system. You must attach a MIDI loopback cable to the device that you are testing.

This test enumerates all MIDI in/out devices by using the midiOutGetNumDevs and midiInGetNumDevs APIs.

Depending on the type of devices that are found (In/Out), the test dynamically decides to run the appropriate test cases.

The application tests for Device Control, Buffer Preparation, MIDI Recording, SysEx Message Recording, and so on.

All test cases return PASS, FAIL or PENDING. You should review the test results in the generated log file for specific details about failures. A test case returns PENDING when it determines that the environment is not set up properly for the test. For example, if the test is run with no output port selected and a given test case requires an output port, the test case returns PENDING.

This test is installed as part of the Microsoft Windows Logo Kit (WLK) (Audio) kit.

Run Time: 10 minutes

Log File:

System Restart Required: No

Test Category:

Supported operating systems for Logo or Signature testing:

  • Windows 7

  • Windows Vista

  • Windows Server 2003

  • Windows XP

Program:

Requirements

Software RequirementsThe test tool requires the following software:

  • Supported operating system (see list above).
  • Software components included with the device that is being tested.

Supported Software

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:
  • MIDI device

Processor

  • x86
  • x64
  • Itanium

Running MIDI Driver Test

Command Syntax

Command option Description

middrv.exe

Without any options, the test starts the user interface.

-c [string]

Starts the application and runs the test cases that are specified in the profile file (.pro) that [string] specifies.

-h [string]

Specifies the Plug and Play (PnP) ID of the device to test. The default value is all devices.

 

Troubleshooting

Test application window logs messages including success/failure results. Test also creates a detailed log file.

Code Tour

File Manifest

File Location

middrv.exe

[testbinroot]\nttest\multimediatest\avcore\audio\wdk\

 

Test Assertions

16.10.1 MIDI Get Device Capabilities - The device must correctly populate the MIDIINCAPS structure on a call to midiInGetDevCaps.

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: The dwSupport field must be 0. The szPname field must be null-terminated. The wMid (Manufacturer ID) field and wPid (Product ID) field must both be registered with Microsoft. The vDriverVersion field must not equal 0.

16.10.2 MIDM_GETDEVCAPS with various sizes of MIDIINCAPS

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: On a call to midiInGetDevCaps, the device must populate the memory that the lpMidiInCaps parameter points to with no more than the number of bytes that the cbMidiInCaps parameter specifies. cbMidiInCaps could even be 0. The device must not cause midiInGetDevCaps to return anything other than MSYSERR_NOERROR in this scenario.

16.10.3 MODM Get Device Capabilities - The device must correctly populate the MIDIOUTCAPS structure on a call to midiOutGetDevCaps.

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: The szPname field must be null-terminated. The wMid (Manufacturer ID) field and wPid (Product ID) field must both be registered with Microsoft. The vDriverVersion field must not equal 0. If the device reports that it is external (wTechnology field equals MOD_MIDIPORT), the wVoices field must equal 0, the wNotes field must equal 0, the wChannelMask field must equal 0xFFFF, and the dwSupport field must not have the MIDICAPS_VOLUME, MIDICAPS_LRVOLUME, nor the MIDICAPS_CACHE flags set. If the device reports that it is internal (wTechnology field equals MOD_SYNTH), the wVoices field must be greater than 0, the wNotes field must be greater than 0, and the wChannelMask field must not equal 0. If the device has set the MIDICAPS_CACHE flag in the dwSupport field, it must force neither midiOutCachePatches nor midiOutCacheDrumPatches to return MMSYSERR_NOTSUPPORTED.If the MIDICAPS_CACHE flag was not set, the device must force neither midiOutCachePatches nor midiOutCacheDrumPatches to return MMSYSERR_NOERROR. If the device has set the MIDICAPS_VOLUME flag or the MIDICAPS_LRVOLUME flag in the dwSupport field, it must force neither midiOutGetVolume nor midiOutSetVolume to return MMSYSERR_NOTSUPPORTED. If neither the MIDICAPS_VOLUME flag nor the MIDICAPS_LRVOLUME flags were set, the device must force neither midiOutGetVolume nor midiOutSetVolume to return MMSYSERR_NOERROR.

16.10.4 MODM Get Device Capabilities with various sized MIDIOUTCAPS

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: On a call to midiOutGetDevCaps, the device must populate the memory pointed to by the lpMidiOutCaps parameter with no more than the number of bytes specified by the cbMidiOutCaps parameter. cbMidiOutCaps could even be 0. The device must not cause midiOutGetDevCaps to return anything other than MMSYSERR_NOERROR in this scenario.

16.10.5 MIDM_OPEN and MIDM_CLOSE with function callback

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When opening an input device with a MidiInProc callback function specified in the dwCallback parameter and the CALLBACK_FUNCTION flag set in the dwFlags parameter of the midiInOpen call, the MIM_OPEN and MIM_CLOSE messages must be passed in the wMsg parameter of the specified callback function when calling midiInOpen and midiInClose respectively. The hMidiIn parameter of the callback function must be the same as the MIDI input device handle obtained from the call to midiInOpen. The dwInstance parameter of the callback function must be the same as the dwInstance parameter passed to midiInOpen.

16.10.6 MIDM_OPEN and MIDM_CLOSE with window callback

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When opening an input device with a window callback function specified in the dwCallback parameter and the CALLBACK_WINDOW flag set in the dwFlags parameter of the midiInOpen call, the MM_MIM_OPEN and MM_MIM_CLOSE messages must be passed in the Msg.message parameter of the specified window callback function when calling midiInOpen and midiInClose respectively. The Msg.wParam parameter of the window callback function must be the same as the MIDI input device handle obtained from the call to midiInOpen.

16.10.7 MIDM_OPEN and MIDM_CLOSE with event callback

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When opening an input device with an event handle specified in the dwCallback parameter and the CALLBACK_EVENT flag set in the dwFlags parameter of the midiInOpen call, the event must be signaled every time either midiInOpen or midiInClose is called.

16.10.8 MIDM_CLOSE while buffers are in the queue

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Calling midiInClose on an opened input device that contains incomplete buffers that are added through midiInAddBuffer must return MIDIERR_STILLPLAYING and must not perform a MIM_CLOSE callback.

16.10.9 MODM_OPEN and MODM_CLOSE with function callback

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When opening an output device with a MidiOutProc callback function specified in the dwCallback parameter and the CALLBACK_FUNCTION flag set in the dwFlags parameter of the midiOutOpen call, the MOM_OPEN and MOM_CLOSE messages must be passed in the wMsg parameter of the specified callback function when calling midiOutOpen and midiOutClose respectively. The hMidiOut parameter of the callback function must be the same as the MIDI output device handle obtained from the call to midiOutOpen. The dwInstance parameter of the callback function must be the same as the dwInstance parameter passed to midiOutOpen.

16.10.10 MODM_OPEN and MODM_CLOSE with window callback

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When opening an output device with a window callback function specified in the dwCallback parameter and the CALLBACK_WINDOW flag set in the dwFlags parameter of the midiOutOpen call, the MM_MOM_OPEN and MM_MOM_CLOSE messages must be passed in the Msg.message parameter of the specified window callback function when calling midiOutOpen and midiOutClose respectively. The Msg.wParam parameter of the window callback function must be the same as the MIDI output device handle obtained from the call to midiOutOpen.

16.10.11 MODM_OPEN and MODM_CLOSE with event callback

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When opening an output device with an event handle specified in the dwCallback parameter and the CALLBACK_EVENT flag set in the dwFlags parameter of the midiOutOpen call, the event must be signaled every time either midiOutOpen or midiOutClose is called.

16.10.12 MIDM_PREPARE and MIDM_UNPREPARE with various buffer sizes

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: The MHDR_PREPARED flag must be set in the dwFlags field of the lpMidiInHdr parameter after a call to midiInPrepareHeader. The MHDR_PREPARED flag must be cleared from the dwFlags field of the lpMidiInHdr parameter after a call to midiInUnprepareHeader. The dwUser field of the lpMidiInHdr parameter must be changed by neither midiInPrepareHeader nor midiInUnprepareHeader.

16.10.13 MODM_PREPARE and MODM_UNPREPARE with various buffer sizes

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: The MHDR_PREPARED flag must be set in the dwFlags field of the lpMidiOutHdr parameter after a call to midiOutPrepareHeader. The MHDR_PREPARED flag must be cleared from the dwFlags field of the lpMidiOutHdr parameter after a call to midiOutUnprepareHeader. The dwUser field of the lpMidiOutHdr parameter must be changed by neither midiOutPrepareHeader nor midiOutUnprepareHeader.

16.10.14 MIDI Start while already recording short message

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.5 and the MIM_DATA message must be received for each MIDI message recorded. The correct MIDI messages must be received by the callback function in the same order they were sent to and recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time that is before the time it was sent. A second call to midiInStart must not reset the timestamp timer back to 0.

16.10.15 MIDI Start while already recording SysEx message

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.5 and the MIM_LONGDATA message must be received for each SysEx message recorded. The SysEx message received must be identical to the one sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to or recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with that is before the time it was sent. A second call to midiInStart must not reset the timestamp timer back to 0.

16.10.16 MIDI Start after recording is stopped

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertions 16.10.14 and 16.10.15, except when midiInStop is called after the first call to midiInStart but before the second call, the second call to midiInStart must reset the timestamp timer back to 0.

16.10.17 MIDI Start after recording is reset

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertions 16.10.14 and 16.10.15, except that instead of calling midiInStart a second time, midiInReset is called in its place. This action must reset the timestamp timer back to 0.

16.10.18 MIDI Start with no buffers to record SysEx message

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.5 and, because no buffers have been added to the input device through midiInAddBuffer, no callbacks must be received for any sent SysEx messages. The input device must ignore any received SysEx messages. MIDI messages, on the other hand must still be received correctly and generate the proper MIM_DATA callbacks.

16.10.19 MIDI Stop while recording SysEx message

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: If midiInStop is called when the input device still has an incomplete SysEx buffer, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInStop was called. The data that the lpData field of the lpMidiInHdr parameter points to must be identical to the data received before the midiInStop call. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter. Any empty buffers in the input queue must not have been returned to the callback. The MHDR_INQUEUE flag must be set and the MHDR_DONE flag must be clear in the dwFlags field of the lpMidiInHdr parameter for all empty buffers.

16.10.20 MIDI Stop after recording is reset

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: A call to midiInStop immediately after a call to midiInReset must return MMSYSERR_NOERROR. Any MIDI messages received before the call to midiInReset must generate the appropriate MIM_DATA callbacks.

16.10.21 MIDI Stop, verify recording stops

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Any MIDI messages sent after a call to midiInStop must not be recorded and must not generate any callbacks.

16.10.22 MIDI Reset while recording SysEx messages

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: If midiInReset is called when the input device still has an incomplete SysEx buffer, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInReset was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received before the midiInReset call. Any empty buffers in the input queue must be returned by MIM_LONGDATA callbacks after midiInReset is called. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter for all returned buffers, incomplete or complete. The incomplete buffer's timestamp must be based off of the call to midiInStart and not based off of the reset timer because of midiInReset.

16.10.23 MIDI Reset after recording is stopped

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.22 and a second call to midiInReset must return MMSYSERR_NOERROR.

16.10.24 MIDI Reset while recording short messages only

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Any MIDI messages sent after a call to midiInReset must not be recorded and must not generate any callbacks.

16.10.25 MIM DATA function callback verification

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.5 and the MIM_DATA message must be received for each MIDI message recorded. The correct MIDI messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with that is before the time it was sent.

16.10.26 MIM LONGDATA function callback verification

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.5 and the MIM_LONGDATA message must be received for each SysEx message recorded. The SysEx message received must be identical to the one sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device. Subsequent messages must have increasing timestamps. The first message must not be stamped with a time before the time it was sent.

16.10.27 MIM LONGERROR function callback verification

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: If an incomplete SysEx message is received, a MIM_LONGERROR callback must be received for that buffer. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the number of bytes received before midiInStop was called. The data pointed to by the lpData field of the lpMidiInHdr parameter must be identical to the data received before the time the midiInStop call. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter.

16.10.28 MIM LONGDATA without callbacks

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When midiInOpen is called with dwCallback equal to NULL and dwFlags equal to CALLBACK_NULL, the driver must still call DriverCallback. This is verified by ensuring that the MHDR_DONE flag is set in the dwFlags field of the lpMidiInHdr parameter to midiInAddBuffer after a SysEx message is received. The SysEx message received must be identical to the one sent.

16.10.29 MODM LONGDATA without callbacks

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When midiOutOpen is called with dwCallback equal to NULL and dwFlags equal to CALLBACK_NULL, the driver must still call DriverCallback. This is verified by ensuring that the MHDR_DONE flag is set in the dwFlags field of the lpMidiOutHdr parameter to midiOutLongMsg after a SysEx message is sent.

16.10.30 MIDM Add Buffer before recording is started

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Calling midiInAddBuffer before recording is started must clear the MHDR_DONE flag and set the MHDR_INQUEUE flag in the dwFlags parameter of lpMidiInHdr.

16.10.31 MIDM Add Buffer after recording is started

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.37 and calling midiInAddBuffer after recording has been started must clear the MHDR_DONE flag and set the MHDR_INQUEUE flag in the dwFlags parameter of lpMidiInHdr.

16.10.32 MIDM Add Buffer with five buffers of various sizes

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.32 must be met for buffers of various sizes.

16.10.33 SysEx message recording with buffers same size as SysEx messages

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.5 and the SysEx messages received must be identical to the ones sent. The dwBytesRecorded field of the lpMidiInHdr parameter passed to the input device by midiInAddBuffer must equal the dwBytesRecorded field of the lpMidiOutHdr parameter of midiOutLongMsg. The SysEx messages must be received by the callback function in the same order they were sent to/recorded by the device.

16.10.34 SysEx message recording with buffers smaller than the SysEx message

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: Requirements of assertion 16.10.34, except that a SysEx message can span more than one buffer. The dwBytesRecorded field of the first buffer must be its size, and the dwBytesRecorded field of the remaining buffers must be either their size (if they're full) or the remainder of the sent SysEx message's size. When appended to each other, the buffers must make up the original SysEx message. Each received buffer must generate a MIM_LONGDATA callback with the proper information. The MHDR_INQUEUE flag must be clear and the MHDR_DONE flag must be set in the dwFlags field of the lpMidiInHdr parameter.

16.10.35 SysEx message recording with buffers larger than the SysEx message

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: 16.10.34 and when a complete SysEx message is received, even if the buffer is not full, it must be returned through a MIM_LONGDATA callback. Its data must be correct just as specified in 16.10.34.

16.10.36 SysEx msg recording and running status

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: SysEx messages must not use running status. Any SysEx message that fails to start with the SysEx status byte must not be recorded and must not generate a MIM_LONGDATA callback.

16.10.37 Short msg recording with running status

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: When messages sent using a running status byte are received, a MIM_DATA callback must be generated and the dwParam1 parameter must be expanded to include the running status byte. Real-time messages must not interfere with a running status and a running status must end when a new status byte is received.

16.10.47 MIDI Volume Control message verification

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: If the wTechnology field in the lpMidiOutCaps parameter equals MOD_MIDIPORT after a call to midiOutGetCaps, the device must support the midiOutGetVolume and midiOutSetVolume calls. If the dwSupport field has the MIDICAPS_CACHE flag set, the device must support a call to midiOutCachePatches.

16.10.48 Basic midiOutGetVolume/midiOutSetVolume test

Test Assertion GUID:

Windows Logo Program: Anonymous

Additional Information: If the device supports volume controlling, it must successfully respond to midiOutGetVolume and midiOutSetVolume calls. This response is verified by setting the volume and getting it to make sure it returns what it was set to.

 

 

Build date: 9/14/2012