[linux-audio-dev] ALSA MIDI latency correction

Peter Brinkmann brinkman at math.TU-Berlin.DE
Mon Aug 1 12:18:21 UTC 2005



Clemens,
Thanks for your reply.

> > and the only solution I have been able to think of is to explicitly
> > schedule events for faster devices at a later time. This is clumsy, and
> > it's exacerbated by the fact that I'd like to schedule events in terms of
> > ticks rather than milliseconds. Since latencies are usually measured in
> > milliseconds, that means I have to convert them to ticks, considering
> > the current tempo of the queue. There's gotta be a better way.
> >
> > Ideally, there are two things I'd like to do:
> >     1. Assign a delay dt to each output port, so that an event scheduled
> >     at time t0 will be sent at time t0+dt. Like this, I could compute the
> >     maximum latency of all my devices, and the output port attached to a
> >     device would get a delay of (max latency - latency of device), so
> >     that everything would be in sync.
> 
> This would just move the ms-to-tick conversion into the ALSA
> sequencer.
Sure, but the ALSA sequencer doesn't seem like such a bad place to put this
functionality;) But seriously, I read between the lines that the solution I
outlined above (latency correction in my top-level code by delaying events,
manually convert ms to ticks) is the correct way to tackle this problem.
Is that right?

> >     2. Automatically determine the latencies of the devices I'm talking
> >     to. In theory, this should be possible. For instance, if timidity is
> >     connected to jack, it could get jack's current latency, add its own
> >     latency, and report the result. Is this science fiction?
> 
> This doesn't help with external hardware synthesizers; you'd have to
> measure how soon after a note-on command its analog output shows a
> signal.
I'd be happy just to have this for soft synths since they seem to be the
main source of latency anyway.
Best,
    Peter





More information about the Linux-audio-dev mailing list