On Sat, Feb 07, 2009 at 11:29:17PM -0500, Alan Stern wrote: > On Sat, 7 Feb 2009, David wrote: > > > Thanks for the pointers Alan. I'm not a developer and never tinkered with > > git before -- pretty slick. > > > > I've isolated it to a patch made on the alsa side under commit: > > > > commit a6a712aeb17ff30206ae1bc827d50497d884602a > > Author: Clemens Ladisch <clemens@xxxxxxxxxx> > > Date: Tue Aug 21 08:56:08 2007 +0200 > > > > [ALSA] usb-audio: allow output interrupt transfers for MIDI > > > > Allow output interrupt transfers for some MIDI devices that require > > them. > > > > Signed-off-by: Clemens Ladisch <clemens@xxxxxxxxxx> > > Signed-off-by: Jaroslav Kysela <perex@xxxxxxx> > > > > > > The patch effectively changed how alsa interfaces with my midi dongle, going > > from using the bulk endpoint to the interrupt one for output. bulk seems to > > work, interrupt, not so much when on ehci. > > That doesn't seem to agree with the description of the patch. Since > your device worked okay using only bulk, no one can claim that it > _requires_ output interrupt transfers. Hence the patch should not have > affected the way the device operates. Yeah. The description doesn't do the patch justice. From what I surmised, they look for a interrupt xfer endpoint and use it if it exists, rather than only using it if it's required. Incidentally, I was able to get the built-in USB MIDI device in one of my synths working -- it supports only bulk and works just fine. I also have two different builds with the only difference being the above patch. It's pretty reproducable, though the severity of the problem does vary from time to time. > > > I'll go ping the alsa folks that surely know more about the midi interfacing > > side of this. But, I have this question for the USB folks: > > > > Why would interrupt transfers behave differently when using ehci and a hub's > > TT vice being native to the ohci hcd? > > I have no idea. In theory the two ought to be equivalent. (However > it should be mentioned that scheduling non-high-speed period transfers > is by far the most complicated part of EHCI, and it's quite possible > that ehci-hcd still has some bugs in that area.) A USB bus analyzer > might be able to detect the differences. > > The only thing I can think of is that the latency for setting up new > transfers might vary. This wouldn't matter if the endpoint's queue is > kept full, but maybe the driver allows it to become empty from time to > time. > Good to know. I did some homework and at least I think I understand the differences between bulk and interrupt xfers. Remember that MIDI is real-time, so there's going to be little to no extra queuing on the endpoint. If this really is a bug in ehci, this could be why it doesn't reveal itself elsewhere. With that said, I think the 1ms retry on USB 1.x interrupt transfers is still plenty fast for a 38.4kbaud data stream and MIDI to be an issue. 125us on ehci to the TT definitely shouldn't be a problem. The artifact seems to be data arriving on the order of a 100+ milliseconds late. Will engage the alsa folks and see where this goes. Thnx again. David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
