Hi All, I'm troubleshooting an AVStream driver that exposes a MIDI pin of DirectMusic type (as well as several audio pins and legacy MIDI). When the DirectMusic MIDI input pin is opened by an application, I'm receiving KSSTREAM_POINTERs with 64 bytes long data members in my process handler. After some research I found that the format of the data is DMUS_EVENTHEADER. Moreover it seems that I'm receiving a buffer for two concatenated DMUS_EVENTs, each 32 bytes long. Unfortunately all this is nowhere documented and just my wild guess, so please correct me if I'm wrong. The strange thing about this is that I don't have any use for the second DMUS_EVENT buffer because I want to send the MIDI messages at the time they come in, and cannot wait for another message to appear to fill the second buffer. If I only do KsStreamPointerAdvanceOffsets() by 32 byte a time, the first message is still delayed until I fill the second one and do KsStreamPointerDelete(). So for the time being I'm using the following workaround: I'm filling the first DMUS_EVENT with cbEvent = 8, all other members = 0 and the MIDI bytes following. and the second one with cbEvent = 8, all other members = 0 and 0xfe (MIDI active sensing) following as dummy data. I'm also setting StreamHeader->DataUsed = sizeof(DMUS_EVENTHEADER)+8 If I do not fill the second DMUS_EVENT, the upper Windows driver stack stops to send new KSSTREAM_POINTERs after receiving a few messages. The same happens if I fill cbEvent with the real size of the incoming MIDI message. So my question is: how am I supposed to fill the StreamPointers and DMUS_EVENTHEADER members correctly so I'm able to avoid the dummy data workaround. Thanks, Stephan ****************** 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.de/