[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