On Tue, Sep 08, 2009 at 02:02:01AM +0100, andy baxter wrote:
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
The path is this;
- keyboard, (Edirol PCR 800),
- USB controller,
- 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
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
1. use arecordmidi to capture the events and see if they are delayed,
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.
Linux-audio-user mailing list