Subject: Re: [linux-audio-dev] MIDI sync issues; mmc, mtc, ...
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Dec 21 2000 - 17:45:04 EET
>Just the thing I meant bring up next. Now even if its doable to implement
>a steady, outgoing MTC stream from a userspace app, it still seems
>difficult to combine it to an existing audio app. If we generate the
>MTC-bytes in the audio loop, MTC accuracy depends on the used buffersize
>(1024 samples frames at 44100kHz -> 23ms per iteration).
Ah, but MTC is based on SMPTE, with a maximum resolution of 1 SMPTE
frame. The wall-clock time of a SMPTE frame varies, but the minimum
value is 1/30 sec or 33msecs. So as long as the fragment size is
smaller than 33msecs, there's no problem whatsoever with the accuracy.
Further, the MTC specification makes it clear (to me at least) that
the MTC master does *not* have to send every timestamp. What matters
is that the messages it does send mark the passage of time in the
correct way. So, if you had a fragment size of 100msec, you just send
an MTC message whenever you can, making sure it indicates the correct
time. MTC receivers should still be able to sync to that. Now, thats
theory. Its possible that some MTC receivers have broken
implementations and fail to do this.
Also, writing
>directly to midi-devices from the audio thread, we risk blocking the audio
>operations. So it would look like we need to do the midi i/o from
>another thread - either put a ringbuffer between the audio and midi
>threads or have the midi thread generate the MTC-bytes itself.
I haven't come up with the right scheme for this yet. On my system, it
takes about 23usec to wake up a different pthread using a
pthread_cond_t, perhaps even faster with a write to a pipe on which
the thread is blocked. So my guess right now is that I will store the
"current MTC time" in a variable, poke the MTC thread (which may be
the MIDI thread itself), and it will send the relevant message.
There are two complications. The first is that either way, this still
involves a system call (pthreads uses kill(2), and the other way uses
write(2)), both of which are potentially bad for the audio thread. The
second is that when the transport is rolling, you generally don't sent
full MTC messages. There is a "smaller version" which just marks
passing frames. Ardour only sends full MTC messages when the transport
comes to a halt for some reason and at the onset of transport motion
(i think). So there would need to be way to indicate to the MTC
thread what kind of message to send.
>Another thing (probably ecasound-specific problem) is what time to
>actually use when generating MTC. For a wall-clock sync, it's reasonable
>to use the "engine-time", ie. how many samples have passed the main engine
>loop. But this won't do if we want to use MTC for syncing audio. Then we
Why not ?
>need to use soundcard's current pointer to calculate the current time...
How would this help ? I don't quite understand what you mean here.
This archive was generated by hypermail 2b28 : Thu Dec 21 2000 - 19:44:26 EET