I have 8 audio tracks, all starting at a START timecode. I have an LTC audio channel coming into my MOTU Ultralite mk3. The LTC starts with the START timecode. The goal is to sync the audio tracks to video, which is being played separately.
How do I do this? I found that I could use a program called “SMPTE Reader” that could get the LTC and send it to ardour but then Jack crashed. So I know ardour can sync, but I can’t figure out how to set it up so Jack is giving the timecode.
LTC timecode is coming in on MOTU analog input #3, and I see no way of telling Jack to expect it there.
There is an option to set whether Ardour expects the incoming MTC to be locked to the same sample clock or not. If that is set true, then Ardour expects no variation in the MTC speed and quite possibly mutes the audio outputs until it sees the MTC arriving at the same speed as its own timeline, and by speed I mean the exact same number of samples per vid frame. If it is set false, then Ardour will vari-speed to follow the incoming MTC and, I would guess, not mute the audio outs.
My guess is that the code that turns LTC into MTC is quite latent and jittery, so with the best will in the world will not be sample accurate for location or speed !
The option can be found in Window->preferences->sync. Turn it off and see what happens.
@markedman9: JACK uses the audio clock used by the audio interface that you told JACK to use. It sounds to me as if the timecode will not be running sync with that, since it appears to come from a separate video playback device that is not sharing an (e.g. blackburst) clock with the audio interface (your MOTU).
i asked this because there is small utility app for JACK that can read LTC from a JACK port and control the JACK transport based on incoming values. however, JACK transport does not provide a mechanism for varispeeding (even by very small amounts) and so this presents issues when the LTC source is not locked to the audio clock. on the other hand, there is the detail that you're only looping a 35 second segment, and any error from lack of varispeeding is likely to be small.
the source code for the tool i am thinking of can be found at http://ltcsmpte.sourceforge.net/ ... to be honest, we really need to merge part of that code into ardour so that ardour can slave directly from LTC (it should be quite easy to do, in fact).
if you have other solutions at this point, i would be looking at them. ardour slaves quite well to MTC, which has always been available in all the testing scenarios that i've had access to. LTC-only sync is likely to still be a headache at this point, I'm sorry to say.
I am a little confused about the clocking. If I tell MOTU to use SMPTE clock as its source, then the MOTU (and thereby JACK), is slaving to the SMPTE clock.
I also want to emphasize that the Ardour2 timeline IS IN SYNC. It appears to be getting the MTC Output from “SMPTE Reader” with no problem, it loops back. The timeline cursor is always in sync. The only problem I am having is that all the audios are muted (mixer indicators are dead). But then when I change to “Internal” clock on Arduor, and hit play, the audio comes out fine.
Am I missing something simple here? Playback is perfect under “Internal”, but puts out no audio under “MTC”.
And I must emphasize that Ardour is getting MTC, not SMPTE. That is what the “SMPTE Reader” software does, convert SMPTE to MTC. And if you say that Ardour syncs quite well to MTC, then why shouldn’t it sync to my application? It is getting MTC.
@paul: incoming timecode runs linearly from 01:01:00:00 - 01:36:00:00, and loops back repeatedly (part of an exhibition that just plays the same piece over and over again). There will be a brief LTC dead period in between playbacks. LTC comes from the analog audio output of a (video) frame-synced media player, so it is derived from the media player’s clock, with the caveat that any adjustments that the media player has to make in order to stay synced with the other media players would seemingly introduce variance up to a granularity of 40 ms (1/25th of a second, 25 fps).
JACK only has access to the MOTU device, and thereby has access to the LTC audio output channel. The MOTU clock is not coupled to the media player’s clock when I set the MOTU clock source to “Internal”. But when I switch it to “SMPTE” the MOTU is slaved to the SMPTE clock.
What audio clock does JACK use? I don’t recall setting this. Perhaps it is whatever I set the MOTU clock to. You should know that MOTU also has some “MOTU SMPTE Console” program, which can stripe, regenerate, or slave other devices on the computer. I didn’t see any options for this working with JACK or Ardour, however.
@seablade: I would be happy to write a bug report. Unfortunately, I don’t have a lot of time to investigate. The exhibition is being installed on Tuesday, and I am looking into other solutions at this point (regrettably, I should say. I would like to use your software and eventually move to Linux). Perhaps I could try one or two things today, but I would not be able to get back to it until the week after Monday.
I set “MTC Output” on lockstep to ardour_in, and then Ardour locked on the MTC beautifully but at first I got no sound. The mixer window showed 8 dead output channels, even though the timeline cursor was playing over the correct audio segment. I quit lockstep, changed Ardour to “Internal”, and it played fine, but without sync, obviously.
And then I changed the clock source on the MOTU to “SMPTE”. And it worked! In sync. I had switched to SMPTE reader (15 min trial on lockstep ran out), but I imagine it would have been the same with lockstep.
And then the video looped back, and again, no audio. All tracks in the mixer window were again dead, even though it was apparently chasing MTC correctly. There was an error “MTC Slave: atomic read of current time failed, sleeping” that appeared 6 times, but I imagine this was the loopback of the video to the starting point.
Hmm place a bug report in Mantis, and if you could jump on IRC during the daytime EST (Via Help>Chat). This sounds like a bug that should probably be sorted out. I have only used it for recording purposes like this, never playback to my knowledge, and even recording I haven’t used that much.