Can ALSA MIDI use timestamps for precise timing?

Can ALSA MIDI use timestamps for precise timing?

[Roger Dannenberg]

Hi,

    I wrote PortMIDI long ago and now that it's going into Audacity and
we're having timing problems in Linux, I'm revisiting the code and
wondering if ALSA has a fundamental design problem. I'm hoping I'm
missing something, but here's the problem:

    PortMIDI wants to send MIDI messages at precise times according to
arbitrary clocks. In Audacity, the important clock to synchronize to is
the audio sample clock. To synchronize MIDI, one can in principle use
timestamps and let the device driver, which presumably runs with very
low latency, dispatch MIDI from a queue to the device or destination.
The question is then what timestamp to use. ALSA has some options.
There's relative timing, but if you send with relative time and you get
unscheduled just as you are executing the write call, you'll be late.
There's absolute timing, but the docs say that's relative to when you
start the queue, but when exactly is that? The problem becomes precise
timing of queue creation doesn't it? And there's no timestamp provided
for when to start. If "absolute" mean exactly the system time, that
would be great, but I think that's not the case.

    Is this a fundamental design error, or am I missing something?

    Thanks. -Roger Dannenberg



_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Can ALSA MIDI use timestamps for precise timing?

[Clemens Ladisch]

Roger Dannenberg wrote:
>     PortMIDI wants to send MIDI messages at precise times according to
> arbitrary clocks. In Audacity, the important clock to synchronize to is
> the audio sample clock.

What is the API that PortMIDI wants to offer?  And does any OS actually
offer this?

The ALSA sequencer relies on interrupts for the clock.  It would be
possible to use a PCM device as interrupt source, but there is only one
interrupt after each period, so this would have horrible jitter.

> There's absolute timing, but the docs say that's relative to when you
> start the queue, but when exactly is that?

When you start the queue, i.e., when you send the SND_SEQ_EVENT_START
message or call snd_seq_start_queue().

> if you send with relative time and you get unscheduled just as you are
> executing the write call, you'll be late.

That could also happen with any other call.

> The problem becomes precise timing of queue creation doesn't it?

You could measure the offset between the queue's clock and the actual
clock.

> And there's no timestamp provided for when to start.

You could schedule the start event, but that would require another
queue ...  ;-)


Regards,
Clemens