[gmpi] Re: Reqs 3.9. Time - opening arguments.1

  • From: Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 05 Feb 2004 11:29:14 -0500

>Mike may correct me, but I think in environments where you are doing hard
>sync of audio to video, there is a house clock that is connected via
>hardware to the audio sample clock.  If an audio plugin only gets to chase
>frames at a frame boundary, it becomes really hard to keep audio smoothly in
>sync without catastrophically dropping samples.

thats not true in situations where you have software rendering of
video to a computer display of some sort. there, you have only the
vertical retrace signal and there is no way to sync that and the audio
sample clock.

yes, to sync you normally drop (video) frames. video because its less
noticeable to our senses to have visual discontinuities.

>So in other words, even in the video sync situation, the free runnning audio
>sample clock is still king.

Its still king, but you still need UST to link the two clocks
together. You need to know that sample S (more precisely, the first
sample of a given process block) "happened" at U1, and that video
frame F was drawn at U2, and then you can sync them together.

Remember: you need to be able to get some time (U1, U2) from a
non-process() context (i.e. when doing video sync). Nothing we have in
GMPI so far is designed to allow an arbitrary component of a
multithreaded plugin to call the host to get "the current sample
time", and i don't actually know of any way you could reliably get
that anyway.

Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: