16 Sep
2005
16 Sep
'05
5:52 a.m.
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.
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.
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? I guess it would be very hard
to synchronize the MIDI commands to the USB frame clock.
Regards,
Clemens