12 Apr
2003
12 Apr
'03
9:31 p.m.
What is the contemporary wisdom from the LAD list gurus about the proper way
to implement MTC sync for sequencers and other tools? There is a lengthy
thread in the archives dating from 2000 which didn't seem to get into the
nitty gritty, and much may have changed in three years anyway.
1) Is the sync properly implemented in a sequencer application, or does ALSA
provide a useful framework for some kind of general solution? I believe that
both Ardour and Muse have MTC implementations built into the applications
(which seem to have rotted at this point; it doesn't seem to work for me).
Why was this, and what are the alternatives?
2) The 2000 thread discussed how bad SMTPE is for audio sync. Unfortunately,
SMPTE/MTP seems to be the standard that is implemented in hardware devices
that we can actually buy. There is probably no point in beating that dead
horse again. It is what we have.
3) Does Jack have a role to play in syncing applications and external hardware
together?
4) Does SMTPE/MTC have a role in software to software sync, or just syncing to
external hardware?
John
14 Apr
14 Apr
10:31 a.m.
1) Is the sync properly implemented in a sequencer
application, or does ALSA
provide a useful framework for some kind of general solution? I believe that
the ALSA sequencer does not do this. it could probably be coerced into
doing so, but it wouldn't work correctly on kernels pre 2.5.6X or
so. the "scheduling" requirements for delivering MTC are impossible to
satisfy in earlier kernels without patches (and not the low-latency
patch, but others).
both Ardour and Muse have MTC implementations built
into the applications
(which seem to have rotted at this point; it doesn't seem to work for me).
Why was this, and what are the alternatives?
see above.
2) The 2000 thread discussed how bad SMTPE is for audio
sync. Unfortunately,
SMPTE/MTP seems to be the standard that is implemented in hardware devices
that we can actually buy. There is probably no point in beating that dead
horse again. It is what we have.
SMPTE/MTC has a resolution of (typically) 1/30 second. it therefore
cannot be used for sample-accurate positioning. this will still ensure
that everything is in the same place, but it may not be exactly where
you want them to be.
3) Does Jack have a role to play in syncing
applications and external hardware
together?
only applications.
see jack/transport.h, but note that it is still evolving. there has
been lots of discussion recently on jackit-devel about the
representation of musical time.
4) Does SMTPE/MTC have a role in software to software
sync, or just syncing to
external hardware?
i hope just the latter.
note: ardour will probably shift to use SMPTE for external h/w sync
soon. SMPTE is an continuous audio signal, and as such it can be
handled precisely without any requirement for precise kernel
scheduling. MTC will be available in slave mode on all kernels, in
master mode on kernels with the new clock support present in the
2.5.6X series.
--p
11:08 a.m.
Paul Davis writes:
SMPTE/MTC has a resolution of (typically) 1/30 second.
it therefore
cannot be used for sample-accurate positioning. this will still ensure
that everything is in the same place, but it may not be exactly where
you want them to be.
This problem disappears when you forget about frames and start looking
at it just as an encoded form of time epressed in seconds. Depending
on the signal quality (no problem with today's hardware), you get an
accuracy of better than a microsecond.
The only problem with SMPTE synchro is that you have to accept that
the 'sample time' of your system is irrelevant w.r.t to the
synchronised content you should deliver, and there is apparently
fierce resistance against that idea.
FA
11:29 a.m.
Just to prevent that someone reinvents the wheel: I have source
code available that does SMPTE decoding (from an audio stream)
Maarten
12:32 p.m.
Maarten de Boer writes:
Just to prevent that someone reinvents the wheel: I
have source
code available that does SMPTE decoding (from an audio stream)
And so have I. In an JACK-like system it gives you the SMPTE time
(in double seconds) corresponding the the current cycle (i.e. time of
first sample of current buffer, and of first sample of the next one).
24, 25, 30 fps, drop frame (compensated) and varispeed.
FA
11:59 a.m.
SMPTE/MTC has
a resolution of (typically) 1/30 second. it therefore
cannot be used for sample-accurate positioning. this will still ensure
that everything is in the same place, but it may not be exactly where
you want them to be.
This problem disappears when you forget about frames and start looking
at it just as an encoded form of time epressed in seconds. Depending
on the signal quality (no problem with today's hardware), you get an
accuracy of better than a microsecond.
The only problem with SMPTE synchro is that you have to accept that
the 'sample time' of your system is irrelevant w.r.t to the
synchronised content you should deliver, and there is apparently
fierce resistance against that idea.
12:26 p.m.
Martijn Sipkema writes:
I think SMPTE should be used to adjust the word clock, either
using external hardware, e.g. a MOTU MTP AV, or by adjusting the clock
of the audio device in software using varispeed. If the audio device
does not support varispeed one could best forget about SMPTE sync
IMHO (or do sample rate conversion to emulate varispeed).
Using SMPTE in this way means SMPTE time == 'sample time' (, the speed
that is..).
I wonder, do there exist cards that allow you to fine tune the word
clock by software ? Given such a card you could have an SMPTE decoder
that adjusts word clock to keep the received SMPTE at nominal speed,
thereby syncing (the speed) of the whole system...
FA
SMPTE/MTC has a resolution of (typically) 1/30 second.
it therefore
cannot be used for sample-accurate positioning. this will still ensure
that everything is in the same place, but it may not be exactly where
you want them to be.
This problem disappears when you forget about frames and start looking
at it just as an encoded form of time epressed in seconds. Depending
on the signal quality (no problem with today's hardware), you get an
accuracy of better than a microsecond.
The only problem with SMPTE synchro is that you have to accept that
the 'sample time' of your system is irrelevant w.r.t to the
synchronised content you should deliver, and there is apparently
fierce resistance against that idea.
1:41 p.m.
[...]
I wonder, do there exist cards that allow you to fine
tune the word
clock by software ? Given such a card you could have an SMPTE decoder
that adjusts word clock to keep the received SMPTE at nominal speed,
thereby syncing (the speed) of the whole system...
This is in fact what I've been proposing all the time and I also
mentioned hardware supporting varispeed IIRC.
And yes. The Emagic Audiowerk8 supports this as do all Sek'd/Marian
cards AFAIK. The RME HDSP devices will be able to do it with a new
firmware.
--ms
12:09 p.m.
SMPTE/MTC has
a resolution of (typically) 1/30 second. it therefore
cannot be used for sample-accurate positioning. this will still ensure
that everything is in the same place, but it may not be exactly where
you want them to be.
This problem disappears when you forget about frames and start looking
at it just as an encoded form of time epressed in seconds. Depending
on the signal quality (no problem with today's hardware), you get an
accuracy of better than a microsecond.
12:42 p.m.
Paul Davis writes:
not for locating to a given position. i know you can
interpolate
running SMPTE, but when you use SMPTE as a point in time to go to,
this option is not available. you therefore can't use SMPTE to specify
sample-accurate edit points, etc.
I really don't see the problem.
IF every cycle is timestamped, then so is every sample.
Say you wand to drop-in at time t. Start playback,
wait until you are in the cycle with t0 < t < t1,
calculate k = floor ((t - t0) / (t1 - t0) * samplerate + 0.5),
switch to recording at the k-th sample.
Now for editing without 'running SMPTE' the only condition is
that your 'content' is defined w.r.t. a 'transport time' in seconds.
You need this mapping anyway in order to sync.
Am I missing something ?
FA
1:52 p.m.
Paul Davis writes:
SMPTE is two things (at least):
* a protocol that encodes time information in an audio stream
* a format for specifying time (HH:MM:SS:FF)
SMPTE cannot specify fractional frames because such things are not part
of the format (my understanding of this is based more on MTC, so
perhaps I need to say that MTC cannot encode fractional frames).
not for locating to a given position. i know you
can interpolate
running SMPTE, but when you use SMPTE as a point in time to go to,
this option is not available. you therefore can't use SMPTE to specify
sample-accurate edit points, etc.
I really don't see the problem.
IF every cycle is timestamped, then so is every sample. Say you wand to drop-in at time t. Start playback,
wrong scenario. suppose i want to store the point in time where (say)
a zero crossing happens. SMPTE will not allow me to do that. i have to
store it as a sample position. if i use SMPTE, then i am not
guaranteed that the result actually refers to the desired sample.
--p
15 Apr
15 Apr
6:38 a.m.
Paul Davis writes:
* a protocol that encodes time information in an
audio stream
* a format for specifying time (HH:MM:SS:FF)
Except for video editors, the HH:MM:SS:FF format is completely
irrelevant. Just think seconds. What the time code does is to
define a relation between a transport position in seconds and a
particular sample. Once you have this mapping, the format of
the timecode does not matter at all.
wrong scenario. suppose i want to store the point in
time where (say)
a zero crossing happens. SMPTE will not allow me to do that. i have to
store it as a sample position.
Again, why use the HH:MM:SS:FF format ? If you divide the 'sample
position' by the sample rate, you get a time in seconds. Conversely,
given a time in seconds, you can find the sample. This has nothing to
do with SMPTE or any other particular time code format.
FA
7:24 a.m.
* a
protocol that encodes time information in an audio stream
* a format for specifying time (HH:MM:SS:FF)
Except for video editors, the HH:MM:SS:FF format is completely
irrelevant. Just think seconds. What the time code does is to
define a relation between a transport position in seconds and a
particular sample. Once you have this mapping, the format of
the timecode does not matter at all.
wrong scenario. suppose i want to store the point
in time where (say)
a zero crossing happens. SMPTE will not allow me to do that. i have to
store it as a sample position.
Again, why use the HH:MM:SS:FF format ? If you divide the 'sample
position' by the sample rate, you get a time in seconds. Conversely,
given a time in seconds, you can find the sample. This has nothing to
do with SMPTE or any other particular time code format.
10:32 a.m.
* a
protocol that encodes time information in an audio stream
* a format for specifying time (HH:MM:SS:FF)
Except for video editors, the HH:MM:SS:FF format is completely
irrelevant.
7921
days inactive
7924
days old
linux-audio-dev@lists.linuxaudio.org
13 comments
5 participants
participants (5)
-
Fons Adriaensen -
John Galbraith -
Maarten de Boer -
Martijn Sipkema -
Paul Davis