[alsa-devel] Can ALSA MIDI use timestamps for precise timing?

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

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
participants (2)
-
Clemens Ladisch
-
Roger Dannenberg