[PD] Timer / metro / realtime

[jma@jeanmarie-adrien.net via Pd-list]

Hi Miller :)
Im running two instances of PD, and the one which is behaving strangely is the one which has no sound, DSP off : it is 0.43.4 extended on a recent Mac (10.9.2). This instance of PD runs mainly sensor analysis via GEM and sound high level control stuff, and, in this process, big CPU load comes from non permanent GEM blob analysis.
This PD instance deals with another PD running in parallel for making sound. For historical reasons, the other instance of pd is an earlier version 0.42.5 , using 8 channels with no driver (core audio).

The metro drift does occur if I run the PD Gem instance only, for a short while, and then returns to a correct behavior
Seems to be quite dependent on the overall load and on the power of the computer (duration of the ‘short while’) :
on mini mac, serious drifts (stress memory) for long time, can even stick false, on mac book pro shorter drift.

Gem instance running alone or in parallel with other PD instance
DSP 140		metro 1000 output 1450 msec
DSP 30		metro 1000 output 430 msec   			happens for a short while (some seconds)	then
			metro 1000 output correct (999/1001)

cheers	
JM







Le 28 juin 2014 à 20:51, Miller Puckette <msp at ucsd.edu> a écrit :

> I've seen this happen lnog ago but not in the past several years at least - the
> cause is probably that the audio driver on your machine is trying to make up
> for lost time somehow.  (Pd uses audo sample I/O to measure time).  If you
> aren't usng audio you can jsut turn DSP off to force Pd to use the system
> clock instead of audio and this should make the problem go away.
> On teh other hand if you need audio I/O on, it migth work to change the
> audio drver (e.g., ise jack if you weren't before, change audio hardware, etc.)
> 
> By the way, what OS and hardware are you using?  (and which Pd)?
> 
> cheers
> Miller
> 
> On Sat, Jun 28, 2014 at 03:42:23PM +0200, jma at jeanmarie-adrien.net via Pd-list wrote:
>> Hi List
>> I have to solve the right way now clock drifts that result from the load of the CPU, because on my recent patches the CPU load varies dynamically enormously, resulting in time measurements totally wrong :
>> 
>> with a very high CPU load the metro 1000 object gives outputs twice too slow, and when bypassing some part of the patch dynamically, reducing the load drastically, the metro runs faster than twice to fast !
>> why does not pd come back to a reasonable time behavior when reducing the CPU load ? it seems that pd stays crazy because of former stress…
>> what is the correct way ? 
>> - make a customized metro with the realtime object ? 
>> - take CPU load in real time to scale logical time measurements accordingly across the patches ?
>> 
>> JmA
>> 
>> 
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140629/a5524b1a/attachment.html>