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 <[email protected]> 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, [email protected] 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
>>
>>
>> _______________________________________________
>> [email protected] mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
