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/
