On Tue, Sep 08, 2009 at 02:02:01AM +0100, andy baxter wrote: > I'm trying to get my usb midi keyboard (an edirol PCR 800) working with > my good laptop (a 1400 MHz core 2 thinkpad X61s). I have jackd running > with 8 msec latency and no xruns using an onboard intel HDA sound card. > When I hook up qsynth (fluidsynth) to the keyboard's alsa midi output, > the notes are triggered with a slight (<0.1s?), and variable time delay. > Sometimes the note plays immediately on pressing the key; sometimes > there is a noticeable delay. This does not happen when I use the same > setup on my old laptop (a 1400 Mhz single core dell). The path from your fingers to your ears is a long one, with many dependencies, so I'd check each part of the path. A useful method is bisection. The path is this; - fingers, - keyboard, (Edirol PCR 800), - USB controller, - interrupts, - processor, - USB controller driver, - USB MIDI driver, - ALSA MIDI output, - qsynth (fluidsynth), - JACK audio, - ALSA HDA driver, - Intel HDA hardware. Ideally, you'd like to know where the delay begins. Based on your description of the problem, the delay begins somewhere between the fingers and qsynth, or in qsynth itself. If it began after qsynth you'd notice gaps in the audio of notes. So we can probably exclude the audio path and concentrate on the MIDI path. What I'd like you to do is probe at the point just before qsynth, and see if the MIDI key down events are arriving delayed. There's several ways of doing this, but I guess two of the simplest are to; 1. use arecordmidi to capture the events and see if they are delayed, or; 2. use a software virtual keyboard to inject events into qsynth, and see if you get the same occasional delays. Now, what if it is qsynth? fluidsynth will read the entire soundfont into memory before synthesis begins, and then lock down the memory to prevent it from being paged out due to other processes' demands. This locking of memory might fail transparently due to process limits. A method I use to check for this is to run qsynth as root. You didn't mention if you do this, so it might be something to try. Given you have a working system and a non-working system, another thing you can do is a recursive diff of the /etc trees on each, to look for any configuration changes you may have made. -- James Cameron http://quozl.linux.org.au/ _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
