[linux-audio-dev] USB-MIDI Transfer rate

[Jens M Andreasen]

On Fri, 2005-09-16 at 09:52 +0200, Clemens Ladisch wrote:
> Jens M Andreasen wrote:
> > I am currently working on digesting the USB-MIDI Class Definition ...
> >
> >  http://www.usb.org/developers/devclass_docs/midi10.pdf
> >
> > As I understand, you can have up to 16 USB MidiStreams (MS), each equal
> > to a physical midi-cable (and each "cable" having 16 virtual
> > midi-channels.)
> 
> Yes.
> 
> > There is a bandwith limit of one 3-byte midievent/ms
> 
> There isn't.  Each USB MIDI packet uses 4 bytes, and the maximum
> packet size of a USB MIDI endpoint is usually between 16 and 64 bytes.
> 
> It would be possible to send more than one USB packet per millisecond
> (bulk transfers can get very near to the theoretical maximum USB
> rate), but the snd-usb-audio driver doesn't bother to do this for
> MIDI.

So there is a bandwith limitation after all, although not implied by the
protocol.


> 
> If the MIDI data doesn't go to a physical MIDI port, the sustained
> bandwidth is indeed much higher than 3 KB/s.
> 
> > The MIDI-USB device also have a control channel without any endpoints
> > (without any physical midi-jacks.) Again only as far as I have
> > understood; the control channel is not a MidiStream and should therefore
> > be able to accept a significantly higher transfer rate than the physical
> > MidiStreams.
> 
> Control transfers always involve an answer sent by the other device,
> and multiple control transfers cannot be sent in parallel, so the data
> rate would be rather low.

In the specific case, I get that the transfer rate on the control equals
a normal midi stream. The data sent to the control is normal midi data. 

Are you absolutely sure that it is not possible to increase the thruput?

> 
> > Question: How do I determine the max transfer rate for the control
> > channel (bInterFaceSubClass == 1) as apposed to the physical midi-outs
> > (bInterFaceSubClass == 3) ?+
> 
> This depends heavily on the device firmware (the answers to control
> transfers can be delayed for several milliseconds).
> 
> > This is for setting LEDs partially lid for more than one parameter, by
> > pulsewidth-modulation over USB-MIDI.
> 
> How much success do you have with this?

Some initial hacks looks promising. There is more afterglow coming from
the leds than expected though. So 10% light looks more like 30%

>   I guess it would be very hard
> to synchronize the MIDI commands to the USB frame clock.

I am not synchronizing anything, just using the big hammer, filling the
stream with data that sets the led on/off in rapid succession

Off:

  off, off, off, off ...

Dull:
   on, off, off, off ...

Somewhat brighter:
   on,  on, off, off ...

etc.

The knob associated with (the ring of) leds sends relative values and
isn't interferring too much at slow turns.

Because of the bandwith limitation, it can of course only look good for
one or two knobs at any one time.

And if you say that this would be much better done in the firmware, I
tend to agree. At least in this case which is directly related to the
purpose of the product. But then again, I have another idea of abusing
some of the ledrings as VU-meters with fading peak indication. At this
point we are kind of leaving sane engineering ...

/jens

> 
> 
> Regards,
> Clemens
> 
--