On Thu, 2016-03-31 at 11:46 +0200, IOhannes m zmoelnig wrote:
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.
Ok, good to know.
both audio and graphics are running in the same thread.
I was actually assuming they're in the same thread, but thought there are two different clocks. I realize now that setting [gemwin] to a frame rate of 60 is not sensible exactly because there is only one clock (the one from the audio card) and that you cannot render quicker than the monitor frame rate (at least not with sync-to-vblank, which seems logical). With a setting of 59 fps all glitches are gone and it seems Pd/Gem doesn't have to wait for the monitor to be ready.
if anything in this thread locks for too long, you might get audible clicks.
Yes.
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.
My thinking was that when I set a high frame rate and and the graphic still runs smoothly, I can use an audio latency that is a little bit higher than the duration of one frame (total_latency = 1/fps + audio_setting_that_works_fine_without_Gem). Which I believe is still true, but _not_ when requesting a frame rate higher than monitor refresh rate.
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.
Thanks for the detailed explanation.
running Gem is a separate thread is not really feasible: (iirc) some frameworks Gem uses MUST run in the main thread.
Not being an expert, I wouldn't have suggested it.
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.
Good to know. In that particular case something is displayed in the gemwin.
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.
I consider myself able to discern analog circuitry noises from noises caused by DSP interruptions. In this case it was clearly drop-outs. But thanks for covering that aspect, too.
Roman