James Cameron wrote: > On Tue, Sep 08, 2009 at 10:14:24AM +0100, andy baxter wrote: > >> - using a program which turns the computer keyboard into a virtual midi >> device. This makes the sound much more immediate. Having tried this, the >> contrast makes it obvious that there is still a problem with delays from >> the edirol keyboard. >> > > Interesting. Let's consider that data path further. > > 1. flow from keyboard USB device to USB controller, > > 2. an interrupt, > > 3. flow from USB controller to processor. > > Perhaps another device on the system is preventing the USB interrupt > from being processed in a timely fashion. See if you can quieten > devices one by one and see if the problem changes. For example you can > quieten a graphics driver by switching to the text console and then > resume playing the MIDI keyboard. > > I've tried running qsynth and jackd from the console with no x session running, and this still doesn't cure the problem. Neither does bringing down the network interface. > General suggestions for a USB flow rate problem ... try different USB > sockets, remove as many USB devices as possible, ensure the cable is > as short as possible, ensure the cable is standards compliant, and if > there is a way to power the device differently (e.g. a DC input socket), > then try it. I've even had particularly strange devices behave better > on a powered hub. > > OK. DC power is tricky for me but could try it. I've tried all the sockets and it makes little or no difference. > Your lsusb shows the device is attached to a USB 1.1 hub. There is a > Freecom Technologies device attached to a USB 2.0 hub. This might be > because the keyboard is only USB 1.1 complaint, I don't know. > > Watch /proc/interrupts while trying to play, and see what counters > increment in the matrix. Here's a fun way ... run this in a terminal > window while playing keys on the MIDI keyboard ... > > watch -d --interval=0.1 cat /proc/interrupts > > I've tried this (nice trick!). It's hard to get precise numbers, but roughly the interrupt rates are: int 0 - timer - 700-1000 per sec. int 17 - sound card - 300-500 per sec. int 21 - edirol keyboard usb hub - 30-50 per sec. LOC - local timer - 150-200 per sec. RES - Rescheduling interrupts - 1000-1500 per sec. > What is the kernel version? You mentioned Debian Testing and Ubuntu > Jaunty. > 2.6.26.8-rt16 on debian testing. > I've looked at the 2.6.30 sources (latest stable), and the USB device > you showed us in lspci "0582:0033 Roland Corp. EDIROL PCR" is listed in > sound/usb/usbmidi.c and also in sound/usb/usbquirks.h . There was > nothing funny about the quirks. > > I've looked at the Ubuntu Jaunty 2.6.28 sources, and usbquirks.h for > this device is no different. usbmidi.c *does* have differences, in that > there have been several fixes in 2.6.30 that might be relevant. Nothing > about the changes looked like an exact match to your problem, but that > could be my inexperience. > > I suggest you try downloading and booting from the Ubuntu Karmic Alpha > CD images that are available now. The newer kernel in those images may > change the timing problem for you. > > OK will give this a try at some point. Cheers for the help. andy _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
