我正在使用来自 C# 的古老的 Windows 多媒体 API（来自 WinMM.dll 的 midiXyz 函数）。
以非流模式 ( )打开 Midi Out 设备/端口后，midiOutOpen使用 ( ) 发送 SysExmidiOutLongMsg工作正常。
以流模式 ( )打开 Midi Out 设备/端口后midiStreamOpen，发送 SysExmidiOutLongMsg不起作用。
相反，midiOutLongMsg失败并出现错误MMSYSERR_NOTSUPPORTED(= 8)。错误文本是：“不支持此功能。使用 Capabilities 功能确定驱动程序支持哪些功能和消息。 ”
但是，根据 MSDN， ( midiOutLongMsg) 也应该与流句柄一起使用。
Jeff Glatt 的优秀 MIDI 信息页面还声称 SysEx 和流媒体可以一起使用（见页面末尾）。
通过使用 ( midiStreamOut) midiStreamOut 将缓冲的 SysEx 消息排入队列来发送缓冲的 SysEx 消息可以正常工作。但是，我也需要/想要直接使用 SysEx 发送midiOutLongMsg。
我已经检查了各种开源 Midi 库（托管和非托管）、几个 Midi 驱动程序源，甚至 WINE 的 WinMM.dll 源，但找不到任何提示我做错了什么。
为了在尽可能少的代码中重现我的问题，我删除了所有回调、未准备、清理和发布内容，并在一个函数中压缩了几个类。以下代码打开第一个 Midi 设备/端口并尝试发送“GM Mode On”SysEx 消息：
2014 年 1 月 12 日更新：请参阅下面的代码版本 3！
public static class MidiTest { // version 1 - x86/32 bit only
public static void Test () {
int moID = 0; // midi out device/port ID
int moHdl; // midi out device/port handle
#if !true
// SysEx via midiOutLongMsg works
Chk (WinMM.midiOutOpen (out moHdl, moID, null, 0, 0)); // open midi out in non-stream mode
#else
// SysEx via midiOutLongMsg fails
Chk (WinMM.midiStreamOpen (out moHdl, ref moID, 1, null, 0, 0)); // open midi out in stream mode
#endif
byte [] sx = { 0xF0, 0x7E, 0x7F, 0x09, 0x01, 0xF7 }; // GM On sysex
int shdr = Marshal.SizeOf (typeof (MidiHdr)); // hdr size
var mhdr = new MidiHdr (); // allocate managed hdr
mhdr.bufferLength = mhdr.bytesRecorded = sx.Length; // length of message bytes
mhdr.data = Marshal.AllocHGlobal (mhdr.bufferLength); // allocate native message bytes
Marshal.Copy (sx, 0, mhdr.data, mhdr.bufferLength); // copy message bytes from managed to native memory
IntPtr nhdr = Marshal.AllocHGlobal (shdr); // allocate native hdr
Marshal.StructureToPtr (mhdr, nhdr, false); // copy managed hdr to native hdr
Chk (WinMM.midiOutPrepareHeader (moHdl, nhdr, shdr)); // prepare native hdr
Chk (WinMM.midiOutLongMsg (moHdl, nhdr, shdr)); // send native message bytes
} // Test
static void Chk (int f) {
if (0 == f) return;
var sb = new StringBuilder (256); // MAXERRORLENGTH
var s = 0 == WMM.midiOutGetErrorText (f, sb, sb.Capacity) ? sb.ToString () : String.Format ("MIDI Error {0}.", f);
System.Diagnostics.Trace.WriteLine (s);
}
[StructLayout (LayoutKind.Sequential)]
internal struct MidiHdr { // sending long MIDI messages requires a header
public IntPtr data; // native pointer to message bytes, allocated on native heap
public int bufferLength; // length of buffer 'data'
public int bytesRecorded; // actual amount of data in buffer 'data'
public int user; // custom user data
public int flags; // information flags about buffer
public IntPtr next; // reserved
public int reserved; // reserved
public int offset; // buffer offset on callback
[MarshalAs (UnmanagedType.ByValArray, SizeConst = 4)]
public int[] reservedArray; // reserved
} // struct MidiHdr
internal sealed class WinMM { // native MIDI calls from WinMM.dll
public delegate void CB (int hdl, int msg, int inst, int p1, int p2); // callback
[DllImport ("winmm.dll")] public static extern int midiStreamOpen (out int hdl, ref int devID, int reserved, CB proc, int inst, int flags);
[DllImport ("winmm.dll")] public static extern int midiOutOpen (out int hdl, int devID, CB proc, int inst, int flags);
[DllImport ("winmm.dll")] public static extern int midiOutPrepareHeader (int hdl, IntPtr pHdr, int sHdr);
[DllImport ("winmm.dll")] public static extern int midiOutLongMsg (int hdl, IntPtr pHdr, int sHdr);
[DllImport ("winmm.dll")] public static extern int midiOutGetErrorText (int err, StringBuilder msg, int sMsg);
} // class WinMM
} // class MidiTest
问题 1：midiOutLongMsg当 Midi 设备/端口以流模式 ( ) 打开时，是否可以通过 SysEx 发送midiStreamOpen？
问题2：如果是，知道我错过了什么吗？
问题 3：我没有找到很多在流模式下使用 MIDI 的源。所以，如果你知道一些在流模式下使用 MIDI 输出的开源库，请给我一个链接，以便我进行比较..
谢谢
更新（2013 年 10 月 19 日）：
嗨，CL，
感谢您的回答。是的，也许微软的某个人在维护 WinMM.dll 时搞砸了一些事情——但我认为我丢失某些东西的可能性更高，因为
a) 有一本旧手册“Windows NT DDK - 多媒体驱动程序”（可在此处获得），它比当前的 MSDN 页面更详细地描述了 WinMM 的内容。第 56 页显示了一个图表，其中 WinMM.dll 作为应用程序和 MIDI/音频驱动程序之间的中间层。WinMM 的主要工作是将 MIDI 数据从应用程序传递到 MIDI/音频驱动程序之一。当 MIDI 驱动程序是外部键盘/合成器/音源的端口驱动程序时，WinMM 无法对 MIDI 数据进行太多更改。第 94 页描述了驱动程序消息 MODM_LONGDATA 及其参数 - 它与 midiOutLongMsg 的参数几乎相同。这限制了在 WinMM.dll 中搞砸的机会。
b) WinMM.dll 中从 midiOutLongMsg 被调用到使用 MODM_LONGDATA 调用驱动程序的代码路径在 midiOutOpen 之后可以正常工作，但在 midiStreamOpen 之后不能正常工作。结果代码是 MMSYSERR_NOTSUPPORTED - 这告诉我，在 WinMM.dll 中的代码路径的开头，我受到了一些健全性检查的打击，比如
if (whatever_weird_condition) return MMSYSERR_NOTSUPPORTED;
而whatever_weird_condition最有可能是关于我应该做但没有做的事情..
c) 如果 MIDI 驱动程序本身不支持流式输出（它是可选的），WinMM 会从缓冲/排队输出 (midiStreamOut) 转换为更简单的非流式驱动程序调用（这不是可选的）。我机器上的 8 个 MIDI 驱动程序都不支持流式传输，都依赖 WinMM 来完成。流式传输短消息和长消息都可以正常工作。
d) 我的测试代码在 Windows 7 和 Windows XP 上的行为完全相同。如果微软把事情搞砸了，那么这个错误一定是很久以前（在 XP 之前）造成的。我是第一个发现它的人（多年后），或者其他人都将它保密且无法搜索。
e) 我的测试代码与我机器上的所有 8 个 midi 驱动程序的行为完全相同。这告诉我，这很可能不是驱动程序问题。
f) 多年的调试告诉我，如果某些东西不能正常工作，那么问题很可能出在我的屏幕一侧.. ;-P