Re: [LAU] midi triggering delay

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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Tue Sep 8 20:15:03 2009