Subject: Re: [linux-audio-dev] MIDI sync issues; mmc, mtc, ...
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Fri Dec 22 2000 - 11:26:27 EET
On Thu, 21 Dec 2000, Paul Barton-Davis wrote:
>>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.
Hmm, here's a quote from the MTC "spec" (not the printed one, I'm not
sure just how official this is):
--cut--
[...]
SMPTE time. It's analogous to the MIDI Clock message. The Quarter
Frame messages are sent at a rate of 4 per each SMPTE Frame. In other
words, by the time that a slave has received 4 Quarter Frame messages,
a SMPTE Frame has passed. So, the Quarter Frame messages provide a
"sub-frame" clock reference. (With 30 fps SMPTE, this "clock tick"
happens every 8.3 milliseconds).
But the Quarter Frame is more than just a quarter frame "clock tick".
The Quarter Frame message's data byte contains the SMPTE time (ie,
hours, minutes, seconds, and frames). SMPTE time is normally expressed
[...]
--cut--
So at least here MTC messages seem to have a twofold role. They both
provide a "sub-frame" clock-reference (~8ms), and the actual absolute wall
clock time. Now an implementation that sends bursts of MTC-bytes every
23ms doesn't seem to fullfil the first requirement.
> 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
How about generating the MTC-bytes in the audio thread and putting
them to a lock-free ringbuffer that's between audio and midi
threads? Midi-thread would handle the actual i/o.
>> 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 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.
When sample data passes the engine (input -> processing -> outputs), there
will be a delay before data is actually outputted from the soundcard. This
would be between [frag_size,max_frags*frag_size]. If we have a soundcard
with 64kB buffer, frag size of 4096B, and we want to fully use the
soundcard's buffer (for instance, we are streaming one audio file to
soundcard along with MTC_sync), we'll have a max delay of 16 fragments (at
44100kHz rate -> 300-400ms).
And of course, this delay is not static, but changes all the time. So the
time used for sending MTC-sync should be 'engine_time - [0ms,400ms]'.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
This archive was generated by hypermail 2b28 : Fri Dec 22 2000 - 11:57:59 EET