Hello, Some time ago we finished our AVStream-based implementation of MIDI filter (used both for playback and recording), however our recent tests revealed some strange issue with MIDI capture. Our AVStrMiniPinProcess function is executed by AVStream core with LeadingEdgeStreamPointer->Offset->Remaining=20 bytes. We fill-in these 20 bytes the following way (based on the information provided by Microsoft, although not found in the DDK): (ULONGs): [0] = KSMUSICFORMAT.TimeDeltaMs [1] = KSMUSICFORMAT.ByteCount = number of bytes to follow [2] = MIDI data [3] = 0 [4] = 0 For short MIDI messages we set ByteCount to 1..3. Here's an example: 00 00 00 00 03 00 00 00 90 40 7f 00 00 00 00 00 00 00 00 00 (3-bytes long short MIDI message 0x90 0x40 0x7f with timestamp set to zero). After processing the buffer, we execute KsStreamPointerAdvanceOffsets(LeadingEdgeStreamPointer,0,20,FALSE); This seems to cause strange issues with user-mode MIDI applications, since they receive additional 'invalid' MIDI message (0x0 0x0 0x0) right after correct MIDI message is received. If we advance the pointer by lesser value (for instance, 12 bytes), AVStrMiniPinProcess is executed with LeadingEdgeStreamPointer->Offset->Remaining set to 8. We cannot fill-in actual MIDI data in this case, because 8 bytes are sufficient for KSMUSICFORMAT header only. If we pass down zeros, this produces the same results as mentioned above. We were unable to find MSDN or DDK/SDK article that would clarify the situation and would help us to solve the issue. Regards, Eugene Gavrilov Software Engineer, CEntrance, Inc. ****************** 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/