• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Audio/Video synchronization
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Audio/Video synchronization


  • Subject: Re: Audio/Video synchronization
  • From: Jeff Moore <email@hidden>
  • Date: Wed, 7 Jun 2006 12:01:37 -0700


On Jun 7, 2006, at 5:15 AM, Rahul wrote:

The master clock is set with the time stamp on the audio packet. This is
done through regular notifications from the input procedure that supplies
data to the Audio Converter (ACComplexInputProc in the PlayAudioFileLite
example). We get the time difference ( in AbsoluteTime) between two calls to
this input procedure. We consider this time difference as the duration of
the sample already played. When this difference adds up to the duration of
the input audio packet we set the master clock to the new audio packet
timestamp.

This calculation has error in it. The current time when your input proc is called is not the time at which the input data was acquired. Thus, the difference between that and the succeeding call is only a very rough approximation of the duration of the packet. At the very least, it contains an enormous amount of jitter due to scheduling latency in the IO thread and any variances in timing in the code path that leads to your input proc getting called.


But the same logic ,
1.for a default output device of 44100 sample rate finds the video running
behind audio
2. default output device of 32000 sample rate finds the audio running behind
video


We have also observed that CoreAudio plays an audio packet for a time more
than its calculated duration . It looks like it is extrapolating the packet.



Any inputs on this? Or is there any other method in CoreAudio ( truly
indicating the playing status) which we could use to update our master
clock.

Basically, you have a case of garbage in/garbage out. The way you are calculating the time stamps is introducing some error into your calculation.


There are any number of alternatives. At the HAL level, the IOProc is handed the time stamp for the data directly (I'm not exactly sure how this time stamp percolates through AUHAL). The HAL also provides AudioDeviceGetCurrentTime() and AudioDeviceTranslateTime() to aid in tracking the audio device's time base.

--

Jeff Moore
Core Audio
Apple


_______________________________________________ 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
  • Follow-Ups:
    • Re: Audio/Video synchronization
      • From: Rahul <email@hidden>
    • Re: Audio/Video synchronization
      • From: Rahul <email@hidden>
References: 
 >Audio/Video synchronization (From: Rahul <email@hidden>)

  • Prev by Date: Re: AudioFile problems with DVI ADPCM files
  • Next by Date: Re: AudioFile problems with DVI ADPCM files
  • Previous by thread: Audio/Video synchronization
  • Next by thread: Re: Audio/Video synchronization
  • Index(es):
    • Date
    • Thread