[wdmaudiodev] Re: Win7 usbaudio.sys MIDI bug?
- From: "Evert van der Poll" <evert@xxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Mon, 30 Aug 2010 00:31:20 +0100
Hi,
It looks like you mixed up controller and program change messages. Controller
message has status byte Bx (where x is channel) and consists of two data bytes.
A program change message has status Cx and only one data byte. The driver
probably interprets this as running status.
Evert van der Poll
-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx]On Behalf Of Daimen Duncan
Sent: Sunday, August 29, 2010 4:13 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Win7 usbaudio.sys MIDI bug?
Hi,
I'm working on drivers for a (bi-directional) USB audio/MIDI device (UAA
compliant at the firmware level). The audio portion works fine on Win7 at
least using the new usbaudio.sys (thanks for fixing that stuff guys! :).
However, I've run into a small bug in the MIDI stuff on Win7.
The MIDI bug is as follows:
If you use a Code Index of 0x0F and just pass MIDI bytes through to USB the
messages are corrupted if they are standard voice messages. Sysex messages go
through fine.
For example, if I send a PC change message of B0 12 using CIN 0x0F the data
received from the Windows MIDI driver is
B0 00
B0 12
Likewise if I send a CC message of C0 01 02 the data received is:
C0 00
C0 01
C0 02
If I send a sysex message the data is fine.
If I parse the incoming messages and assemble them into packets with the
appropriate CIN then it works fine but I don't have enough memory in the
microcontroller and I really shouldn't have to parse them since we're just
passing them from the MIDI IN jack to the PC. The USB box isn't creating MIDI
messages, it's just receiving MIDI data from it's jack and putting it on the
USB bus.
So two questions:
1) Is this a bug/known issue? Can someone on the Windows audio team chime
in and confirm... if/when there will be a fix?
2) If the answer to the above is no/never... what's the fastest/easiest
approach to a workaround in the stack? A filter driver above/below usbaudio?
Thanks,
drd
Other related posts:
