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

[Theo Burt]

Chris and Cyrille, thank you both for this very useful information and 
ideas for testing etc. I will investigate some more and post results 
when I get some.


Thanks to all
Theo

On 19/07/2012 13:49, chris clepper wrote:
On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt > wrote:



Does anyone know how the vsync works on OSX? I mean how does GEM
wait for the vsync, to flip the buffer? Does it block the process
at any point? Is the process blocked by any part of GEM at any
point, on a per frame basis?


VBL sync is a single line of code that turns it on/off.  GEM's render 
engine doesn't do anything different based on that state.



For example, after the all the opengl has been executed, I'm
presuming a system call is made to actually render the screen?
What is this call, and could it simply be that something, perhaps
operating system related, is causing it to take too long to
return? That would tie in with moving windows around the desktop
making the problem worse...


The last call in any GL chain is glFinish() which flushes all of the 
commands to the card via the driver.  The driver can block the 
uploading of commands to the card for various reasons most of which 
are not documented anywhere.  Apple has OpenGL profiling tools that 
can show where time is being spent in the driver.




___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[chris clepper]

On Thu, Jul 19, 2012 at 6:14 AM, Theo Burt  wrote:

>
> Does anyone know how the vsync works on OSX? I mean how does GEM wait for
> the vsync, to flip the buffer? Does it block the process at any point? Is
> the process blocked by any part of GEM at any point, on a per frame basis?
>

VBL sync is a single line of code that turns it on/off.  GEM's render
engine doesn't do anything different based on that state.


>
> For example, after the all the opengl has been executed, I'm presuming a
> system call is made to actually render the screen? What is this call, and
> could it simply be that something, perhaps operating system related, is
> causing it to take too long to return? That would tie in with moving
> windows around the desktop making the problem worse...
>

The last call in any GL chain is glFinish() which flushes all of the
commands to the card via the driver.  The driver can block the uploading of
commands to the card for various reasons most of which are not documented
anywhere.  Apple has OpenGL profiling tools that can show where time is
being spent in the driver.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[Cyrille Henry]

hello,



Le 19/07/2012 12:14, Theo Burt a écrit :

Thanks everyone for all their suggestions. Unfortunately, I can't run the 
graphics on  a different thread, as they are so tightly integrated with data 
from the audio thread.

i understand that separating audio and video can be very complex, but i think 
that's the only solution to be very accurate.
don't forget that netsend/netreceive work very well on localhost...




Does anyone know how the vsync works on OSX? I mean how does GEM wait for the 
vsync, to flip the buffer? Does it block the process at any point? Is the 
process blocked by any part of GEM at any point, on a per frame basis?

the best is to make tests and report result in this list.
by example, you can open an empty gem window rendering at 120fps, using a vsync 
to a 60fps screen.
then, use a simple osc~ to produce sound and record the result with an other 
software.
i supect that you'll have on average 8ms of sinusoid, then 8ms of silence. this 
would indicate that pd process is completely stop during vsync wait. well, 
things can be a bit more complex as chris explain, but that's a good staring 
point to understand how things work.
a metronome should also be 2 time slower that what it should.
I don't use osX, so i can't make this test for you.

you can also try to remove vsync, in order to check that you'll have no more 
sound problem. unfortunately, this usually result in horrible visual artefact.
i don't know how to do that on osx.

working on single buffer should not have this sync, but you'll not be frame 
accurate, and you'll still have visual artefact, but you can use this mode for 
tests.



For example, after the all the opengl has been executed, I'm presuming a system 
call is made to actually render the screen? What is this call, and could it 
simply be that something, perhaps operating system related, is causing it to 
take too long to return?

i suspect that the return of the call is made only when the flip is made.


That would tie in with moving windows around the desktop making the problem 
worse...

OR, (and this may sound strange), there's no possibility for a denormal to 
creep in anywhere is there? It's just what happens to the system (the whole of 
PD seems to slow down to about 50% while the glitches are going on) is 
particularly reminiscent of denormal issues I've had in the past...


denormal problem cause CPU to increase.
if pd wait for vsync, then cpu decrease.


cheers
c




On 17/07/2012 23:15, chris clepper wrote:

On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry mailto:c...@chnry.net>> wrote:

oh, on linux you can't render faster than the screen.
i supposed that it was the same on osX, but i'm may be wrong.
if you can render faster than the screen, then the proposed
solution will not work, and i have no other solution, and no
explanation for the problem.


GEM is certainly sending the GL commands at whatever rate you set, but I 
honestly don't know for sure what happens in the GL driver and on the GPU when 
setting the GEM frame rate higher than VBL sync.  Maybe the extra rendering 
commands are ignored or maybe not.


___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev




___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev



___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[Theo Burt]

Thanks everyone for all their suggestions. Unfortunately, I can't run 
the graphics on  a different thread, as they are so tightly integrated 
with data from the audio thread.


Does anyone know how the vsync works on OSX? I mean how does GEM wait 
for the vsync, to flip the buffer? Does it block the process at any 
point? Is the process blocked by any part of GEM at any point, on a per 
frame basis?


For example, after the all the opengl has been executed, I'm presuming a 
system call is made to actually render the screen? What is this call, 
and could it simply be that something, perhaps operating system related, 
is causing it to take too long to return? That would tie in with moving 
windows around the desktop making the problem worse...


OR, (and this may sound strange), there's no possibility for a denormal 
to creep in anywhere is there? It's just what happens to the system (the 
whole of PD seems to slow down to about 50% while the glitches are going 
on) is particularly reminiscent of denormal issues I've had in the past...



On 17/07/2012 23:15, chris clepper wrote:
On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry > wrote:


oh, on linux you can't render faster than the screen.
i supposed that it was the same on osX, but i'm may be wrong.
if you can render faster than the screen, then the proposed
solution will not work, and i have no other solution, and no
explanation for the problem.


GEM is certainly sending the GL commands at whatever rate you set, 
but I honestly don't know for sure what happens in the GL driver and 
on the GPU when setting the GEM frame rate higher than VBL sync. 
 Maybe the extra rendering commands are ignored or maybe not.



___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev




___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[chris clepper]

On Tue, Jul 17, 2012 at 5:59 PM, Cyrille Henry  wrote:

> oh, on linux you can't render faster than the screen.
> i supposed that it was the same on osX, but i'm may be wrong.
> if you can render faster than the screen, then the proposed solution will
> not work, and i have no other solution, and no explanation for the problem.


GEM is certainly sending the GL commands at whatever rate you set, but I
honestly don't know for sure what happens in the GL driver and on the GPU
when setting the GEM frame rate higher than VBL sync.  Maybe the extra
rendering commands are ignored or maybe not.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[Cyrille Henry]

Le 17/07/2012 23:46, chris clepper a écrit :

On Tue, Jul 17, 2012 at 5:09 PM, Jack mailto:j...@rybn.org>> 
wrote:



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 ?
Maybe the best is when you have Gem fps as a multiple of your screen fps ?
Thanx for the rest of explanation.
++


The GPU has at least two buffers for drawing to screen.  The back buffer is 
where all of the rendering is done and the front (or display) buffer just gets 
a copy of the back buffer at a specified interval.  The idea is that rendering 
can take a long time while a copy cant be done quickly (GPU VRAM copies are 
insanely fast now), so you can take almost all of the render time to draw the 
frame then swap buffers at the last instant and then go back to rendering.

I initially set the OSX version of GEM to VBL sync to remove the 'tearing' 
artifacts that horribly plagued other software (Nato advertised it as a 
feature).  I wanted smooth HD video regardless of GEM render rate and used VBL 
sync and async texturing to do it (this also ended up in the VLC GL rendering 
code on OSX that I advised on a long time ago).

Using VBL sync will only flip the back buffer to the front at 60 fps.  It 
should be possible to feed GL and the GPU more data than the 60 FPS you need 
but it might not be displayed.  Or maybe the results will be indeterminate?  It 
could be back to the tearing issue if the back buffer is partially filled at 
swap time.

oh, on linux you can't render faster than the screen.
i supposed that it was the same on osX, but i'm may be wrong.
if you can render faster than the screen, then the proposed solution will not 
work, and i have no other solution, and no explanation for the problem.
c




I used to know all of the guys who wrote the Mac drivers and made the ATI 
chips, but we have all gone on to other things, so I can't get a definitive 
answer right now.


___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev




___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[chris clepper]

On Tue, Jul 17, 2012 at 5:35 PM, Cyrille Henry  wrote:

>
>
> 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.
>
>
There could be locks on the back buffer when using VBL sync that would
prevent anything more frequent than 1/VBLrate to actually render into it.
 So you might have a situation like this:

render 10ms wait 6.6ms render 3.4ms render 10ms wait 3.3ms to get two
frames.  As I wrote previously, I used to know who to ask to get the actual
answer to this, which was great because the GPU people are really secretive
about their black boxes.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[chris clepper]

On Tue, Jul 17, 2012 at 5:09 PM, Jack  wrote:

>
>
> 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 ?
> Maybe the best is when you have Gem fps as a multiple of your screen fps ?
> Thanx for the rest of explanation.
> ++
>
>
The GPU has at least two buffers for drawing to screen.  The back buffer is
where all of the rendering is done and the front (or display) buffer just
gets a copy of the back buffer at a specified interval.  The idea is that
rendering can take a long time while a copy cant be done quickly (GPU VRAM
copies are insanely fast now), so you can take almost all of the render
time to draw the frame then swap buffers at the last instant and then go
back to rendering.

I initially set the OSX version of GEM to VBL sync to remove the 'tearing'
artifacts that horribly plagued other software (Nato advertised it as a
feature).  I wanted smooth HD video regardless of GEM render rate and used
VBL sync and async texturing to do it (this also ended up in the VLC GL
rendering code on OSX that I advised on a long time ago).

Using VBL sync will only flip the back buffer to the front at 60 fps.  It
should be possible to feed GL and the GPU more data than the 60 FPS you
need but it might not be displayed.  Or maybe the results will be
indeterminate?  It could be back to the tearing issue if the back buffer is
partially filled at swap time.

I used to know all of the guys who wrote the Mac drivers and made the ATI
chips, but we have all gone on to other things, so I can't get a definitive
answer right now.
___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[Cyrille Henry]

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 gl

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

[Jack]

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 ?
Maybe the best is when you have Gem fps as a multiple of your screen fps ?
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@iem.at
>> http://lists.puredata.info/listinfo/gem-dev

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

[Cyrille Henry]

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.

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




___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[Jack]

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

Hello,

Can you provide a small exemple patch with this trouble ?
When you use Gem and sound, it is a good practice to separate these two
process on different cores to avoid glitch.
You have 2 solutions to achieve this :
- use [pd~] (see the help patch)
- use 2 instances of Pd, one for Gem, the other for the sound, and send
data between these two instances with [netsend]/[netreceive] (the system
should manage these two instances on different cores).
++

Jack



___
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev

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

[Theo Burt]

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