Re: Audio Running faster then Video
Re: Audio Running faster then Video
- Subject: Re: Audio Running faster then Video
- From: Eric Lee <email@hidden>
- Date: Tue, 9 Aug 2005 16:11:27 -0700
Hi Marc,
If I remember correctly, the time stamps that Core Audio gives you
comes from the audio device's clock.
What you are seeing is normal. If you are writing your own playback
engine and outputting video and audio to the devices independently
based on each device's own clock, they will drift out of sync since
the clocks run at ever-so-slightly different rates.
You cannot, as far as I know, tell Core Audio to use another device's
clock, so the easiest solution would be to drive the video based on
the audio clock.
Barring that, you will unfortunately have to do your own
synchronization. In the AudioTimeStamp structure, the mFlags field
will tell you which of the fields are actually valid. In practice,
the mHostTime or mSampleTime fields are probably the most useful.
Simply adding zeros or removing samples might work, but you might
hear clicks and pops in your resulting audio. The best way would
probably be to time-stretch the audio.
Eric
-------------------------------------------------------------------
Eric Lee
Media Computing Group Email: email@hidden
RWTH Aachen University Phone: +49-241-80-21056
Ahornstr. 55, Room 2U11 Fax : +49-241-80-22050
52074 Aachen, Germany http://media.informatik.rwth-aachen.de
On Aug 9, 2005, at 3:30 PM, Marc Van Olmen wrote:
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:
40rwth-aachen.de
This email sent to email@hidden
_______________________________________________
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