[PD] DSP and Gem in the same instance of Pd

[Roman Haefeli]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160331/52a7f8d1/attachment.sig>