[KnownBugs]

There are a few bugs known both located in the OSS driver
as well as in this firmware. We're currently in the process
to track them down.


- BUG #0 (firmware)

  When the device is booted while MIDI IN event come in, the
  IN (reading) pipeline gets blocked, so that one cannot read
  from the midi device(s).

  Workaround: unplug MIDI IN on the device before the downloading
  process happens.


- BUG #1 (firmware/OSSdriver)

  When first opening the device, one might get old data from
  some buffers. As MIDI is a real time infrastructure, this
  is illegal.

  One might discuss, whether the issue is located in the
  ezusbmidi firmware or in the OSS driver. It does not appear
  with the ALSA driver, as this one constantly polls the events
  so that the events do not pile up in the firmware.

  Because there is no real open or close in the USB world, we
  tend that the OSS driver should be adjusted accordingly.


- BUG #2 (OSSdriver)

  The usb-midi driver (OSS) might drop first bytes send after reopen.


- BUG #3 (OSSdriver)

  Poll (select) in OSS driver is aparently broken in two ways:

  It may signal data available to read (though there are non)
  and block then (correctly) the next read. It may also (and that
  happens with read too), simply block without delivering data.
  These problems are aparently triggered by open/close calls,
  even on other devices.

  I was not able to reproduce the bug lately.


- BUG #4 (firmware?)

  On 2x2 when running testlb simultaniously on both cables
  repeatingly, drops (or something like crosstalk as the
  pipelines are cloned) appears. The test is not yet specific
  enough to describe the problem precisely. Running the tests
  on only one channel aparently always succeed after initial
  resyncronizing over BUG #1 and #2.

  But only when one loops back A-OUT-A-IN, B-OUT-B-IN.
  In a A-OUT-B-IN and B-OUT-A-IN wireing problems appear
  which really suggests some kind of cross talking between
  the cables.

  As the 1x1 has only one cable, this bug does not appear there.

- BUG #5 (OSSdriver)

  Pulling the USB plug, when writing to or reading from the device
  causes the system to lock up. Might have likely issues unloading
  the module.


* There might be more issues both in the driver(s) and the firmware.

  We have designed a loop back test procedure, located and described
  in more details in the "regression" directory. We are very dedicated
  to assure production quality of both drivers and firmware. Until now,
  i wouldn't rely on the stuff when recording my next album. For less
  demanding operation you might find the material in good shape, though.

