Re: Audio Running faster then Video
Re: Audio Running faster then Video
- Subject: Re: Audio Running faster then Video
- From: Marc Van Olmen <email@hidden>
- Date: Fri, 12 Aug 2005 12:31:18 -0400
Hi,
Thanks for all responses.
but after further testing and analyzing I found a decompression bug,
that was causing the de-synchronization issue of 1 second.
I currently have done all my testing with an Aurora Pipe Pro: NTSC
playback
and now playback the 2 hours 42 minutes clip 4 times in a row so more
then 11 hours of playback. The audio and video stayed synchronized at
sample level precision.
So this confirms that I was thinking those PCI video cards have locked
clocks for Audio and Video.
I gonna do some testing now with a Decklink Blackmagic card, although I
personally prefer Aurora Pipe Pro, this card works like a swiss clock,
and thanks again for all your input!!
greetings,
mvo
On Aug 9, 2005, at 6:30 PM, Marc Van Olmen wrote:
hi,
Using Aurora Video card.
I'm writing my own playback engine and I'm in the end of testing now
very long movies ( 3 to 4 hours). so I'm coming to the subject of
synchronizations. I just got the video fixed because now I use the
Quicktime call
"::ClockGetTime(fVideoOutputClockInstance,&aTimeRecord);" instead of
the CPU time and the video is now running on the correct time...
Proof: The Aurora driver put's it self in a
while (RightTimeToStartTransfer)
;
loop. Before i was using the CPU Clock ( which I knew I had to correct
in the end). So after 10 minutes the cpu time went all the way up 105%
and dropped then suddenly back to 25%. So the Aurora driver was
compensating itself to correct the wrong frame sending time by my
application.
So the Transfer Time of frames went all the way up to 33 milliseconds.
So in that point my application dropped one frame.... so I lost a
frame every 15 minutes.
Now playing a movie of 5 hours, the cpu time stays around 25% and the
transfer speed to the Aurora PCI card stays around 3-4 milliseconds.
And never goes up higher then 5 milliseconds... I record maximum
transfer time so I know for certain....
I'm telling this video story because I think the symptoms I'm seeing
now are Audio related... so that's why I'm here:
I can tell you that the for a movie with a duration of 2 hours 45
minutes. The Audio finishes about 0.933 seconds sooner then the Video,
this process happens gradually. I have the impression that the Audio
is on the CPU clock and not on the VideoCard clock? I know for a fact
that the Audio goes to the right output.
I use coreAudio with rendercallback technique:
// Get the format that the AudioUnit expects us to give it
input.inputProc = cNode_AudioOutput::DoAudioOutputCallback;
input.inputProcRefCon = this;
BAIL_OSERROR(AudioUnitSetProperty( fOutputAudioUnit,
kAudioUnitProperty_SetRenderCallback,
kAudioUnitScope_Global,
0,
&input,
sizeof(input)));
And I sync the start of the video and Audio, by giving 0 samples to
the audio card until the first video frame is ready transfer....
DoAudioOutputCallback ( void * inRefCon,
AudioUnitRenderActionFlags *ioActionFlags,
const AudioTimeStamp * inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList * ioData)
Questions for finding a solution:
==================================
Question 1:
-----------
Is there a logical explanation for what I'm seeing.
Question 2:
-----------
Is it possible that coreAudio uses the CPU clock and not the Device
(in my case Aurora Video Card) clock?
Is it possible to check that? Or is there an option to change the
clock in coreAudio????
Question 3:
-----------
Do I need to do my own synchronization? So sometime adding a few 0
samples or removing a few samples (just incase....) to do my own
synchronisation.
But I need some guidance on how best approach this like which timer I
would use to synchronize the Video clock and Audio clock from the
parameters:
struct AudioTimeStamp
{
Float64 mSampleTime;
UInt64 mHostTime;
Float64 mRateScalar;
UInt64 mWordClockTime;
SMPTETime mSMPTETime;
UInt32 mFlags;
UInt32 mReserved;
};
I'm using I will need to use the mHostTime and I need to compare that
with the videoClock and in case the are too far off???? I need to add
a few 0 samples or distribute them over time so I don't hear the
difference....
Is that correct? I remember vaguely a discusion from Jeff Moore about
this
thx and much thx for extra lighting
mvo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden