On Fri, 2005-09-16 at 09:52 +0200, Clemens Ladisch wrote: So there is a bandwith limitation after all, although not implied by the protocol. 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? Some initial hacks looks promising. There is more afterglow coming from the leds than expected though. So 10% light looks more like 30% 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 --

On Fri, 2005-09-16 at 17:10 +0200, Clemens Ladisch wrote: I have: [jens@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@c80-216-125-193 ~]$ cd /sys/class/usb_host/usb1/device/usb1/1-2/ # the control ? [jens@c80-216-125-193 1-2]$ cat 1-2\:1.0/bInterfaceSubClass 01 [jens@c80-216-125-193 1-2]$ cat 1-2\:1.0/bNumEndpoints 00 # midi out jacks ? [jens@c80-216-125-193 1-2]$ cat 1-2\:1.1/bInterfaceSubClass 03 [jens@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?) This will change all ports, no? Both internal as well as external? 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 --

On Mon, 2005-09-19 at 10:03 +0200, Clemens Ladisch wrote: I am running into troubles here. After reboot, the usb-midi goes haywire!? And I have not even done any changes to the system yet ... At first, I reboot with the usb device off and then have a peek: $ ls /dev/midi* /dev/midi1 $ amidi -l Device Name hw:1,0 MPU-401 MIDI 1-0 .. which looks as expected. But then turning the device on gets weired: $ amidi -l Device Name hw:1,0 MPU-401 MIDI 1-0 ls /dev/midi* /dev/midi /dev/midi1 /dev/midi2 /dev/midi3 .. which is no good. The /dev/midi* devices are too many and not working. Turning the usb device off again leaves me with: $ ls /dev/midi* /dev/midi1 /dev/midi3 I experience that at random times, the system actually wakes up in a working state. I am still to figure out what that pattern is? mvh // Jens M Andreasen (going down for reboot) --

On Wed, 2005-09-21 at 09:54 +0200, Clemens Ladisch wrote: Thankyou! Now to get back to the subject. By changing 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; .. I get a 16 fold increase in thruput. Test data was a SysEx dump for upgrading the firmware which used take ~25 sec, now ~1.6 sec. The cute little LCD progress animation isn't really visible anymore, but the update appears to be intact. mvh // Jens M Andreasen --

On Fri, 2005-09-16 at 17:10 +0200, Clemens Ladisch wrote: Well, as said elsewhere; (in this case) it is 16 times higher than you (by default) allow for in usbmidi.c While trying to catch up, I noticed that there is a "FIXME" in --------------------- static void snd_usbmidi_standard_output (snd_usb_midi_out_endpoint_t* ep) ... // FIXME: lower-numbered ports can starve higher-numbered ports ------------------------ Uhmm ... I have been meditating on this function all evening. There are implications surrounding it. You have decided to go for the worst case scenario where an USB 4byte-frame == a 3byte-midi-msg == 1 milisecond. The obvious anvantage is that this will not break. Although, for a physical cable there are best case scenarioes where you can get 3 messages across/milisecond (ie: channel aftertouch) I also noticed that the driver envestigates quite a few vendor/product IDs to get around various "quirks". This route might be a way to go? mvh // Jens M Andreasen --