On Thu, 2016-03-31 at 11:13 +0200, Roman Haefeli wrote: > Hey all > > It's a well know issue and the solution has been discussed many times: > When you're using audio and Gem rendering, it's wise to separate those > two into their own instance of Pd. > > I'm working on a project that does both, audio processing and Gem > rendering. The OpenGL rendering is very light-weight and does only > require minimal resources. Also the audio part uses a fraction of the > available CPU power. What I observe is that I get a zipping noise for > ~15 seconds, then clean audio for another 15 seconds before the zipping > noise returns. The zipping noise occurs only when Gem rendering is > turned on. > > To me it looks like the problem is not related to limited resources, > rather it seems that both, OpenGL and audio rendering, are tied to their > respective clock and those clocks are not coupled and thus are not > completely in sync. > > I know I could put both parts into their own instances of Pd and that's > what I'll do if there is no resolution, but for convenience reasons I'd > prefer to have only one patch in one instance of Pd. Now, is there a way > to loosen the coupling to OpenGL clock (is it the same as the monitor > clock?) so that audio is not affected? I don't care about any > side-effects like tearing (it won't be visible anyway for the kind of > image).
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. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
