reliable, exact A/V sync

gringotron's icon

I'm using Max 5.0 in a research setting, presenting videos with sound to human subjects. I'd like to ensure that audio and video are perfectly (within 10ms) in sync upon delivery to the subject, and currently am using jit.qt.movie and spigot~ to achieve playback.

I am looking at the A/V sync by running the video signal through a VGA->composite video converter, and then running the video and audio signals into an oscilloscope to measure the delay between the two. However, the amount of delay between the two is completely unpredictable and varies by +/-20ms or more during sequential, identical runs.

The jit.qt.movie object is receiving timing from a qmetro with a timing value of 5.

I've tried all audio drivers available to me, and experimented with latency settings, but even without changing settings the A/V sync delay is unpredictable from one playback to the next.

What can I do to ensure more reliable sync?

Thanks in advance!

Joe Bell's icon

Apologies my advice is not comprehensive, but you'll be best off syncing the video to the audio rather than audio to video. In other words, consider working out your frame/time ratio and do a direct frame request, that way dropped frames wont cause you to go out of sync. I'm sure others will have better responses.

gringotron's icon

So judging from the lack of responses, this looks like an issue that isn't very common. I went ahead and took measurements of Max's sync performance, and figured someone here might find it useful after all:

I ran the VGA output from my laptop through a VGA->composite video converter (Grandtec GEZ-1000), and connected the composite video signal to an oscilloscope. I then connected the audio output of the laptop to a different channel on the scope.

I created a video which consists of black video and no audio for three seconds, followed by a synchronized white+tone burst. For triggering purposes, a small audio blip was placed two frames before the sync burst. By watching the two scope traces during the white+tone burst, a measurement was made of the asynchrony between the two.

Trials: using each of ASIO, mme, and directsound drivers, varying latency when possible, performing 50-100 trials for each setting. Additionally, a/v playback was tested with two methods: jit.qt.movie + spigot~, and sfplay~ + sync outputs to jit.qt.movie via frame requests.

Results: Average asynchrony between audio and video varied from over 20ms (ASIO) to nearly 0 (mme with a certain latency). However, a more interesting result is that the standard deviation of the asynchrony was nearly identical for ALL settings and drivers: approximately 14-15ms. This was even true for both software sync approaches mentioned above, as well as for multiple different computers (running WinXP). What this tells me is that there are some OS/hardware/other factors which are always present, and which always account for roughly 15ms of unpredictability in a/v synchrony. Not perfect, but I'll live with it, and the lesson I'm taking away from this is that for good a/v sync, extensive tweaking for a particular system is required.

Thanks Walter for the suggestions--just thought this info may help someone in the future!

justin's icon

i would suggest maybe trying metro rather than qmetro.
i would also tie the interval of metro to the desired frame rate, currently you are asking jitter to run at 200fps... is that really necessary?

qmetro, as i understand it, is designed as a timing system which can delay/drop frames, which is desirable in a real-time environment...

using metro, and having overdrive switched on, should improve timing accuracy, but it depends on your jitter needs / available cpu. you might find that jitter struggles to play, or worst case scenario max freezes...

just a thought,

Justin