[PD] Timer / metro / realtime

[Miller Puckette via Pd-list]

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