On 2016-03-31 11:19, Roman Haefeli wrote:
BTW: Why does the graphics rendering|clock have precedence over the audio rendering (at least, it seems to be like that in Pure Data/Gem)? I guess most softwares do it the other way around, since clicks are much more noticeable than a frame being a few milliseconds late.
it doesn't. both audio and graphics are running in the same thread. if anything in this thread locks for too long, you might get audible clicks.
now Gem is violating the first rule of realtime programming ("never do any system calls in a realtime thread")¹. Each frame (whenever the actual drawing is done) the gfx card will stall the Pd-thread for a short time. if the gfx-driver is configured to sync to vblank (to avoid tearing), then this short time might be considerably longer, as the thread is stalling until the next vblank (which might happen only 1/60s in the future). so turning off sync-to-vblank is a good start. but even so, the process might get stalled for a short(er) period. so the next thing to do is to raise Pd's system latency, so it buffers enough to cater for dropouts.
running Gem is a separate thread is not really feasible: (iirc) some frameworks Gem uses MUST run in the main thread.
other things to consider: depending on what you want to do, you might consider rendering "nothing" (e.g. if you are using Gem for motion tracking, there is no reason why you would need to display anything; since Gem requires a window to do anything, just make it super small and make sure to not call anything talks with the gfx-card (anything openGL). of course, this might totally not work for your project.
also: the "zipping noise" you describe might be something else than a "dropout". it might be that the noise is actually generated in the analog circuitry of your motherboard (e.g. on some systems i hear a zipper noise whenever i move the mouse; or display a certain pattern on the screen). if this is the case, try isolating the audio circuit from the video circuit, e.g. by outputting audio via toslink and using an external D/A-converter.
fgmasdr IOhannes
¹ Gem is not alone here. virtually all objects (there are of course exceptions, like [readsf~]) that do system calls (like reading a file) are not realtime safe. with most of these objects you can get away by only calling the non-realtime-safe operations during initialisation. With a realtime renderer, this is obivously not possible.