Re: [LAU] midi triggering delay

James Cameron wrote:
> 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.
>
>

Thanks. I had a look at the qsynth settings and found that the sample
rate, buffer size, and buffer count were different from that set in
qjackctl, (also it was using 16 bit samples instead of floats). Changing
all these to the same as jackd seems to have improved the situation, but
not completely cured the problem as far as I can tell. There still seems
to be a very slight delay between hitting the key and hearing a note,
but it's smaller and more consistent than before. It's getting to the
point though that it's hard to tell whether the delay is there or not.

I'll try what you suggested to see if I can improve things a bit more.

Cheers,

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 12:15:01 2009