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

[Jens M Andreasen]

On Fri, 2005-09-16 at 17:10 +0200, Clemens Ladisch wrote:
> Jens M Andreasen wrote:
> > On Fri, 2005-09-16 at 09:52 +0200, Clemens Ladisch wrote:
> > > > 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 speaking about the device's control pipe or about a MIDI port
> that happens to be labeled "control"?  The former _cannot_ be used to
> send MIDI data, and the latter is just a standard USB MIDI stream.
> 

I have:

 [jens at c80-216-125-193 ~]$ amidi -l
 Device    Name
 hw:1,0    MPU-401 MIDI 1-0
 hw:2,0,0  BCR2000 MIDI 1 <-- this one is internal only
 hw:2,0,1  BCR2000 MIDI 2
 hw:2,0,2  BCR2000 MIDI 3

but then
[jens at c80-216-125-193 ~]$ cd /sys/class/usb_host/usb1/device/usb1/1-2/

# the control ?
[jens at c80-216-125-193 1-2]$ cat 1-2\:1.0/bInterfaceSubClass 
01
[jens at c80-216-125-193 1-2]$ cat 1-2\:1.0/bNumEndpoints 
00

# midi out jacks ?
[jens at c80-216-125-193 1-2]$ cat 1-2\:1.1/bInterfaceSubClass 
03
[jens at c80-216-125-193 1-2]$ cat 1-2\:1.1/bNumEndpoints      
02


.. hey, wait a second. I am apparently misinterpreting these numbers
because when I change the internal routing to the simplest possible (no
midi in/out), they stay the same ... 
(bangs head in wall, and where did I displace my cluestick?)

> > Are you absolutely sure that it is not possible to increase the thruput?
> 
> Try changing the line:
> 
> 	ep->max_transfer = usb_maxpacket(umidi->chip->dev, pipe, 1);
> 
> in the snd_usbmidi_out_endpoint_create function in usbmidi.c to:
> 
> 	ep->max_transfer = 512;
> 

This will change all ports, no? Both internal as well as external?

> or even bigger values.  This should result in more than one packet per
> frame.
> 
> 
> It would be interesting to know what the maximum data rate is.
> 
> 

Indeed :) 

The transfer rate for physical cables is known and works perfectly well
with the current implementation. Transfer rate for internal elements is
not known and I can think of several reasons that it is probably
considerably lower than the theoretical max USB transfer rate. Mike Kent
mentions that the device can throttle data ... Let him explain with his
own words:


(from mikekent)
-------------------
Data sent over the  virtual MIDI cables is _not_ bandlimited. If the
specification implies this please tell me the section so I can check it
for errors.

Of course, data sent from the host to an External MIDI OUT should be
bandlimited to consider the speed of the classic MIDI cable. The host
may have a mechanism for this. The Bulk transfer mechanism also provides
a way for the device to throttle data coming from the host in case the
host is not taking care of band limiting.

But data sent to an Element may be sent at any rate necessary, limited
only by bandwidth currently available on the USB. This is one of the
reasons we chose Bulk as the USB transfer type for this specification.
Your device could define an Element as the internal consumer of the MIDI
control data you are sending.

You could also use the High Bandwidth Data Transfer Mechanism (Section
5.2.1) on Transfer bulk IN and one Transfer bulk OUT endpoints of you
want to send non-MIDI data.

Best Regards,
Mike.
----------------------


So we would like to discover that the Element is an internal consumer
and then also monitor if we exceed the capabilities of the device. In
the general case, this may depend on the kind of data send, ie setting
up a note-on with voice stealing might be more expensive than a humble
pitch-bend.

In the specific case (lighting up the leds), the cost is constant for
all midi-data.


mvh // Jens M Andreasen

> Regards,
> Clemens
> 
--