[QLab] Audio & video out of sync due to recording?

[Pierre-Luc Brunet]

Hi guys,

I just finished a run of musical here where the musical director and I wanted to record the show. Due to limited resources I decided, even thought wasn't the safest idea, to record it with the same computer and audio card that is outputting the sound effects and videos (using Qlab) for the show. This operating did not overload the CPU or RAM.

So the first video we played, the audio and video seemed to be slightly off sync then on the 2nd it seemed to be just fine and then got bad and really bad. Toward the end of the show there was about 1.5second lag on the audio. 

So towards the end i stopped the recording, quit the software (I was using Logic 8) but nothing changed. 

Then there was a point where i could do a STOP ALL and reload the cues and it seemed fine from there.

After the show I tried to recreate the problem without success. Could it be due to I/O Buffer size used in the recording software? In my tests it didn't seem change much. Can it have something to do with the length of the recording as well?

Here is what i use:

Running Qlab 2.3

Logic 8.0.2

Macbook pro 15" (5.1) 2.8ghz - 4 gig of ram plenty of hard drive space. The extra video card was off.

Sound card: Motu 828 MKIII 

Running video from mini display port to VGA to a dual head to go.

Only 2 channels of audio outputs are used and 5 inputs for the recording.

Does anyone have thoughts on this?

I know doing the playback and recording on the same machine wasn't the greatest idea but it would be awesome if it can be achieved without issue.

Thank you.

--
Pierre-Luc Brunet
514.209.9393
pierrelu...@gmail.com

[*]

Pierre-Luc,

Out of curiosity, what application were you recording video too & what was
the video source? Onboard Isight?

Thanks,

*

On Sun, May 30, 2010 3:41 pm, Pierre-Luc Brunet wrote:
> Hi guys,
>
> I just finished a run of musical here where the musical director and I
> wanted to record the show. Due to limited resources I decided, even
> thought
> wasn't the safest idea, to record it with the same computer and audio card
> that is outputting the sound effects and videos (using Qlab) for the show.
> This operating did not overload the CPU or RAM

________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

[Pierre-Luc Brunet]

Hmm I thinking I was not very clear. We recorded only the audio of the show (So the singers and the band) not the video.

And when we played video out of Qlab, the audio wasn't sync with the videos.

[Andy Leviss]

On Mon, May 31, 2010 at 2:19 AM, Pierre-Luc Brunet
<pierrelu...@gmail.com> wrote:
> Hmm I thinking I was not very clear. We recorded only the audio of the show
> (So the singers and the band) not the video.
> And when we played video out of Qlab, the audio wasn't sync with the videos.

Was this audio that was part of a video, or separate audio files? If
the latter, did you have "guarantee sync" checked on those cues?

[Pierre-Luc Brunet]

What was off sync was the audio embedded in the video files.

And I was recording only the live mics, not the playback. And this issue only happened when the recording was happening this afternoon. 3 other shows and 2 dress rehearsals (without recording) went without issues.

[Christopher Ashworth]

Odd. I'm not exactly sure what might have happened.

For the record, video in QLab syncs to the internal clock of the computer, rather than the clock of an audio device (if the video has audio). Audio syncs to the audio device. So I can only assume that the audio device clock somehow drifted dramatically, but I'm not sure how/why.

(I realize video should ideally be synced to the audio device too, and there's some preliminary code in there that does this, but for technical reasons I won't get into here I haven't felt comfortable releasing it in this form; the internal clock has generally been reliable.)

-C

[Christopher Ashworth]

On May 31, 2010, at 6:50 AM, Christopher Ashworth wrote:

> there's some preliminary code in there that does this, but for technical reasons I won't get into here I haven't felt comfortable releasing it in this form; the internal clock has generally been reliable.

(Guess it's time to take another crack at this, though.)

-C

[Pierre-Luc Brunet]

For the record, video in QLab syncs to the internal clock of the computer, rather than the clock of an audio device (if the video has audio).  Audio syncs to the audio device.  So I can only assume that the audio device clock somehow drifted dramatically, but I'm not sure how/why.

Does this mean that when a setup uses an external audio card and there are videos that have an audio track. The video part uses the internal clock while the audio of the same file uses the audio card clock?

If so, that is interesting and generally it works no problems.

Or when a video has an audio track, the whole thing syncs to the external clock?

I might do some testing of this situation to try to recreate it but that probably won't happen for at least 2, 3 weeks. Busy, busy.

Thank you for the info.

[Sean Dougall]

On May 31, 2010, at 11:05 AM, Pierre-Luc Brunet wrote:

For the record, video in QLab syncs to the internal clock of the computer, rather than the clock of an audio device (if the video has audio).  Audio syncs to the audio device.  So I can only assume that the audio device clock somehow drifted dramatically, but I'm not sure how/why.

Does this mean that when a setup uses an external audio card and there are videos that have an audio track. The video part uses the internal clock while the audio of the same file uses the audio card clock?

Yes (currently). In fact, the same is true for the built-in audio output as well; the audio will use the sound card's clock, but the video goes off the processor clock. The short explanation is that QuickTime is in charge of the video playback rate and CoreAudio controls the audio playback rate. This way you can guarantee that the movie's audio track will not drift from other audio cues that might need to stay synced -- but the video is basically just playing at the computer's native rate.

As Chris said, ordinarily this system works fine; you'd have to have something go unusually awry to get a noticeable drift from the video... but then, that's what seems to have happened in your case. It's just not clear why. Do you have any aggregate devices set up, by any chance? Or is the MOTU resolving to any external clock source?

Cheers,

Sean

[Pierre-Luc Brunet]

Very interesting. There are 2 aggregated devices made in the computer but I was not using either of them. Soundflower is also installed but again not used in this case but both aggregated devices and soundflower systems are patch to patch 2 through 5.

And the Motu is all alone on its own internal clock.

Thanks.

________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com

[Charles Coes]

What sampling rate were you recording at?  I wonder if the computer was having issues recording at one sample rate and playing back at another.  

Charles Coes
cco...@gmail.com 
www.charlescoes.com
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." - Buckminster Fuller

[Pierre-Luc Brunet]

Recording and playback both at 44.1khz. 

And i'm not sure if this is a clue but at the end of the show i closed logic. It didn't change anything but when I did a STOP ALL in Qlab and then reload the next video that one seemed to be fine.

[raymond soly]

Hmmm.....I am thinking different frame rates for the video(on internal clock) and the qlab &logic (from MOTU) !!!!! the MOTU will default to a "master" sampling/frame rate, that will usually be the Qlab session rate when using only Qlab ....but if logic somehow takes the session over and, evn though it has the same sampling rate, its frame rate might be different (29.97 vs 30 or 29.97 nd etc.....) that might be enough to explain the progressive lag...........as you said at the end of the session you closed logic and all was fine......you might want to look in the logic sync prefs ........

hope this helps........

Ray

[Pierre-Luc Brunet]

Another interesting thought. It seems like the fps of the logic session is 25fps and sync mode set to internal.

Is the fps of the Qlab video clock determined by the videos themselves? 

If so the fps of my videos is 29.97 so that could maybe the problem.

I must clarify thought that closing logic did NOT solve the problem. I was only when i did the  STOP ALL in Qlab that it seemed to have fix it.

Thank you for the thought!

[raymond soly]

Pierre Luc, in Logic although the sync mode is set to internal, changing the sampling rate and fps will change the system clock on the motu to the new rate/fps.regardless of what was used before ........or at least that is how it behaves with my motu 896hd......therefore when you quit logic the motu system is still "locked" at the logic rate/fps and "Stop all" in qlab seems to reinitialise the motu to the rate/fps used before......maybe?!! 

R