On Fri, 2007-10-12 at 00:48 +0200, cyrille henry wrote: > > Thomas O Fredericks a écrit : > > "sync to vblank will sync swapping buffer with the screen frame rate, but > > that's not the original question. > > to my knowledge, there is no possibility to sync gem rendering with the > > screen frame rate. > > if you fix both at 60Hz, you can have jitter (not a lot, but some)." > > > > You are not technically syncing gem to the screen frame rate. > yes > > You are > > syncing the open gl redraw to the framerate. > yes > >The GPU takes care of that. > > > i don't understand this. > > if you get gem to render a 60FPS, you will have 60fps based on the pd (cpu) > clock.
i don't know this by reading the code, but for me it would only make sense to get the clock from the audio-card, nothing else. this is also what i experienced, when pd was running on jackd, while jackd was believing to be running at 44100Hz, while it was actually at 48000Hz. all [metro]s were too fast and all pitches too high. the only objects, that seems to work not with the audio-clock, that come to my mind, are [cputime] and [realtime] (is that true?) > if you set your screen at 60fps, you will have 60fps based on the gpu. > there is no way to make the cpu clock to be exactely the same speed as the > gpu clock. > so, sometime (specially with big patch), you can have desincronisation > between this 2 clocks, even if they should be at the same speed. > (there is a also a lot's of jitter in pd clock) what makes you think that? i 'd claim, that pd's clock is stable, unless you get audio drop-outs. roman ___________________________________________________________ Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list