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 <[email protected]
<mailto:[email protected]>> 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
[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
