[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


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?


  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?


Other related posts: