Paul Davis wrote:
Yes, "transport sync" is the right term and that is waht "we" need.
So the rest, my argumentation, is just blah-blah:
Digital audio audio has got a resolution of 1 sample. Maybe audio and
light waves have got a resolution of a Planck length?
MTC and SMPTE should sync computers to digital or analog audio or video.
What "we" need is a sync that is accurate enough to sync to video half
frames, film frames, sequencer tics etc. in a way that no phases can be
heard when 2 machines are playing the same audio signals in unison, film
cut needs to be possible for exactly 1 picture. This is possible by MTC
and SMPTE. MTC and SMPTE aren't for sync of digital audio IOs, sync of
video refresh rates etc..
You might be right, times have changed, maybe something "better" is
needed for the future, but today MTC and SMPTE are still needed because
a lot of equipment is using this time-codes and they are accurate enough
if everything is fine. SMPTE between a Yamaha 4 track tape recorder and
an Atari ST was good enough to play a synth recorded to the audio tape
and played by the sequencer in unison, without any noticeable delay,
even simple click signals for sync, used by the C64, were able to do
this. Something that isn't fine for my actual Linux PC, because of
jitter. I know that other people don't have noticeable jitter for their
Linux PCs, but I guess even for those machines sync isn't without jitter.
There's no need for a theoretical perfect accuracy, "we" only need the
possibility to sync different machines without noticeable delay.
For people who have better luck than I've got MTC can sync different
machines to Linux good enough, only SMPTE for some applications is
missing, because video equipment is using SMPTE and not MTC.
If people will sync blender to a tape recorder or external video machine
JACK transport or MTC aren't a help.
SMPTE is used by people because it's fine ;), it does what it should do :).
Linux-audio-dev mailing list