[GEM-dev] Problem with glitching on OS X at high frame rates

Tue Jul 17 23:35:42 CEST 2012

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
>>> GEM-dev at iem.at
>>> http://lists.puredata.info/listinfo/gem-dev
>>>
>>
>>
>> _______________________________________________
>> GEM-dev mailing list
>> GEM-dev at iem.at
>> http://lists.puredata.info/listinfo/gem-dev
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://lists.puredata.info/listinfo/gem-dev
>