Upon checking the source code of dlls/quartz I found out about the method SetSyncSource defined in the IBaseFilter interface:
dsoundrender.c:static HRESULT WINAPI DSoundRender_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filesource.c:static HRESULT WINAPI AsyncReader_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) filtergraph.c:static HRESULT WINAPI MediaFilter_SetSyncSource(IMediaFilter *iface, IReferenceClock *pClock) parser.c:static HRESULT WINAPI Parser_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) transform.c:static HRESULT WINAPI TransformFilter_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock) videorenderer.c:static HRESULT WINAPI VideoRenderer_SetSyncSource(IBaseFilter * iface, IReferenceClock *pClock)
In particular, I see the following two things about sync sources: 1) I see no effort on part of filtergraph.c to add a sync source when simply asked to render a file 2) Even if it did, current implementation of videorenderer.c does nothing with its sync source
So I have a couple of questions: 1) Am I right to assume that a sync source might be used to synchronize and (if necessary) drop frames at the videorenderer in order to maintain synchronization and avoid stuttering? 2) Could the sttutering really be solved by implementing the using and passing of a synchronization source (systemclock.c) in file rendering? If so, then the migration to DirectDraw would become just an optimization to increase the frame rate.
Alex Villacís Lasso