If I set the second cbEvent to zero, then Windows stops to send me new
mappings after I have submitted a few MIDI messages (it stops after
sending about 60 mappings). Thus my input starves then.
I do not change the allocator framing from the initial setting (one
page, two frames). Will try that.
Stephan
On 20.02.2004, at 20:18, Matt Gonzalez wrote:
What happens if you set the second cbEvent to zero?
Matt
Stephan Kappertz wrote:
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/
******************
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/
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/
