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 <ch@chnry.net mailto:ch@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