Re: midi triggering delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux