> > When QuickTime reaches a loop point in a movie, a SetTime is
> > internally generated to jump back to the loop point. The timebase
> > runs continuously through this action, and the video display tends to
> > be fairly smooth across this transition. However, the audio queue is
> > flushed and audio data starting at the new position is transmitted.
> >
> > For reasons having to do with the stability of the DirectSound audio
> > data callbacks, we have a fairly deep safety buffer for queuing audio
> > samples...nearly a half a second (as opposed to a small fraction of
> > that in MacOS). In order to keep audio and video in sync, this means
> > that the first half-second of audio at the loop point is silent while
> > the newly queued samples move through the safety buffer. This
> > doesn't happen on the initial play, or when you jump to a new
> > position in the file, because we delay the start of video to line up
> > with the playback of the first audio sample.
> >
> > We already have a bug request to improve this behavior by queuing
> > audio around the loop point, but the behavior for now, on Windows
> > platforms, is pretty much what you've observed. Application writers
> > that would prefer to hear all the audio data, rather than preserve
> > the forward motion of the timeline, may manage the looping manually
> > by setting a timebase callback for the loop endpoint, and issuing a
> > Stop/SetTime/Start sequence to restart at the loop start.
> >