Le 17/07/2012 23:09, Jack a écrit :
Le 17/07/2012 21:36, Cyrille Henry a écrit :
hello,
osX synchronize openGL rendering to the screen. i.e if your external
screen is at 59.9 fps, Gem will not be able to render more than 59.9 fps.
since Gem rendering is connected to pd timing, it is connected to
audio processing. i;e : if gem is only able to compute 59.9 fps when
60 is asked, then pd time will not be synchronize with real world
time. so you have click on the sound.
(desincronize openGL render to screen is usually not an option, since
result are ugly with fast moving images)
moreover, Gem rendering are computed during pd data processing, i.e.
between every audio block. by default, pd use 64 sample buffer. so pd
compute audio buffer every 1.5ms. You have to expect a bit of jitter
on the 16.666ms needed between 2 images rendered, accentuating
previous effect. (if gem image is rendered 17ms after the previous,
one have to wait an extra 16 ms...)
Using faster computer will not solve this problem. using faster screen
will offer a solution, but that's not a good solution for me, and
probably not for you.
If you really need frame accurate render, easiest solution is to
desynchronizes sound and image processing. pd~ is not an option since
the 2 process will have the same timer.
So, you have to use 2 pd, one for the sound, one for the image,
synchronised using netsend / netreceive (on localhost). The best is
probably to ask 100fps to Gem, so that it will sync to the screen
frequency, whatever the screen is). Then, you should use the screen
frequency as the time base of your performance.
Hello Cyrille,
If you have Gem at 100 fps and you screen at 60 fps, you should
encounter a problem of sync at a certain moment, no ? If not, can you
explain more ?
if you ask Gem to render at 100Fps, you'll have a new image 10ms after last
render.
if your screen is rendering at 60fps, it ask for 16.6 ms between 2 images.
so, after having render a frame, gem will wait for the scren 6.6ms on average.
everything will be hang during this 6ms.
pd time will desincronize from real time.
that's why the clock from this pd can not be used to compute audio.
but since pd timing is more than 6ms acurate, you can be certain that every
computed frame will be rendered for 16.6ms
So this result on using a timing based on the screen.
you can use this pd the send bang to an other pd that compute the sound.
Maybe the best is when you have Gem fps as a multiple of your screen fps ?
in theory, if all clock are perfect and syncronized.
that's what theo was tring with gem at 60fps and screen at 60 fps.
using gem at 30fps give good result exept that :
- 30 fps is to slow
- since there is few jitter on gem (that can be reduce using pd -noaudio), and
since diferents clock are not syncronized, every image will be display on the
screen for 32ms on average, but some will be for 16ms other for 48.
++
c
Thanx for the rest of explanation.
++
Jack
using this solution is not to hard to have sound synchronize on screen
rendering.
hope that help, don't hesitate to ask more precision if i'm not clear.
Cyrille
Le 16/07/2012 19:31, Theo Burt a écrit :
Hi, me and a friend of mine do a lot of live audio-video performance,
professionally, all using pd/gem as an environment. We both use
Macbook Pros (different models), and for the last couple of years
we've been having a serious problem which we now suspect is something
to do with GEM/PD, rather than, for example, the graphics cards or
drivers.
The problem occurs when running at higher frame rates - it is highly
preferable for us to run at 60 frames per second, because (1) it
syncs with the refresh rates of most projectors and seems to produce
much smoother/more regular movement, and (2) often we are using very
precise, high frequency flashing, for optical effects, that we need
to be able to sync exactly with screen refreshes. We are generally
running the gem window in a second screen (such as a monitor or
projector), but it happens when running on one screen too.
As soon as we run at 60 frames per second (or near it), glitching
starts to occur frequently in the audio, and the audio goes out of
sync with GEM. While the glitching is occurring, processes in PD and
GEM jerk along, pausing frequently. To resolve it (temporarily), the
audio has to be reset in PD (by reselecting the audio device). The
glitching then goes away and everything runs smoothly, but it returns
spontaneously after a short time. The glitching is also exacerbated
by moving windows around on the screen. It might be worth noting that
the same patch running on the very same machine in Windows XP (using
bootcamp) does not have this problem.
We have different GPUs, mine is a Nvidia 9600m GT, and his was an ATI
of some sort. We are using very simple, geometric graphics, and are
not approaching the processing limits of the GPUs at all (if I do
push the graphics card very hard, I notice that frames are skipped
rather than glitching occurring). I also note that it happens equally
when there is low CPU activity, so it's not related to that.
My friend has just purchased a new Macbook Pro, yesterday with a 60%
more powerful Nvidia GPU, and unfortunately the glitching is still
occurring. It occurs in OS X Lion, and also was happening in Snow
Leopard. We've tried disabling power management on the GPU, and this
doesn't help either.
I've looked through the gem code in an attempt to try and understand
what is happening, but I am afraid it is beyond me!
Does anyone have any idea at all what the problem could be? It would
make such a huge difference to us if we could resolve it. Thanks very
much for any help in advance (and for developing GEM in the first place)
All the best, Theo
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
_______________________________________________
GEM-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/gem-dev
