[LAU] midi triggering delay

[James Cameron]

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/