yes, its like that. pd eats all aviable processor resources after suspend until i close it. i have compiled version 0.42.5 without any errors on my ubuntu karmic (x64), using AMD Turion MK-36
i can't reproduce this :
pd 42.5 ubuntu karmic i386
however, after suspend, pd have to compute everything that as not been computed during suspend. so it can eat all cpu for some time, until it sync again with real time. this is only if a patch that use cpu is open during suspend.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, i logged in.
yes, but it is curious, why pd have to compute everything what had to be done during sleep? it sounds useless.
i tried suspend my computer (for 5sec) with opened pd, but without opened patch, it happens again - eats all aviable cpu (until i kill the proces), but no patch opened.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With Pd 0.41.4 extended on OSX 10.5 the same behaviour happens. More specific I have noticed this: a switched-on metro object will send all it's suspended messages at wake up after sleep. This makes Pd using 99% cpu during some time, depending on the length of sleep period.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
katjav, could you try a nightly build on Mac OS X? I am guessing this is related to the 'audio stuck' code, which has been disabled on Mac OS X builds of Pd-extended.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It took me a while to find out under what exact conditions the phenomenon happens. But for me on OSX 10.5 it is like this: when dsp is turned on, then off again, and the computer is put to sleep mode and waked up again, metro will instantaneously count all it's lost ticks. However, it does not happen with dsp on while going in sleep mode, and also it does not happen when dsp is still "off" after Pd startup. (Is DSP really off at startup?).
I tried these things with Pd extended 0.41 but also with the latest build of 0.42.5-extended-rc1. The behaviour is the same for both versions, as far as I can see.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should better include the patch which I used to check these things.
#N canvas 628 67 463 505 10;
#X obj 98 198 metro 1000;
#X obj 98 250 +;
#X msg 98 223 1;
#X floatatom 98 278 5 0 0 0 - - -;
#X obj 98 173 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X msg 51 223 0;
#X text 11 222 reset;
#X msg 10 111 \; pd dsp 1;
#X obj 10 52 loadbang;
#X obj 77 87 delay 1000;
#X msg 77 111 \; pd dsp 0;
#X text 10 12 patch for testing sleep behaviour of [metro];
#X text 148 119 1: make sure DSP is turned on and then off.;
#X text 132 172 2: activate metro.;
#X text 135 279 3: watch seconds being counted in normal conditions
;
#X text 13 320 4: put your computer to sleep for a couple of minutes.
;
#X text 13 349 5: wake up your computer and watch the seconds-counting
box. Metro will probably execute all the ticks which it missed while
sleeping. This can cause considerable CPU load \, up to 100%. After
a couple of hours of sleep and with a faster metro speed \, CPU overload
may last for minutes.;
#X text 14 430 6: reset counter \, turn DSP on and do sleep - wake
up again. Probably you will find that the abovementioned behaviour
does not happen now.;
#X connect 0 0 2 0;
#X connect 1 0 3 0;
#X connect 2 0 1 0;
#X connect 3 0 1 1;
#X connect 4 0 0 0;
#X connect 5 0 1 1;
#X connect 5 0 1 0;
#X connect 8 0 7 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i can't reproduce this :
pd 42.5 ubuntu karmic i386
however, after suspend, pd have to compute everything that as not been computed during suspend. so it can eat all cpu for some time, until it sync again with real time. this is only if a patch that use cpu is open during suspend.
ok, i logged in.
yes, but it is curious, why pd have to compute everything what had to be done during sleep? it sounds useless.
i tried suspend my computer (for 5sec) with opened pd, but without opened patch, it happens again - eats all aviable cpu (until i kill the proces), but no patch opened.
An example patch is always very helpful, especially if it triggers the problem every time that it is run. Ideally the example patch would have only enough objects to cause the problem, but nothing else.
Cannot reproduce using Pd version 0.42.5-extended-20100120 on Mac OS X 10.5.8.
With Pd 0.41.4 extended on OSX 10.5 the same behaviour happens. More specific I have noticed this: a switched-on metro object will send all it's suspended messages at wake up after sleep. This makes Pd using 99% cpu during some time, depending on the length of sleep period.
katjav, could you try a nightly build on Mac OS X? I am guessing this is related to the 'audio stuck' code, which has been disabled on Mac OS X builds of Pd-extended.
It took me a while to find out under what exact conditions the phenomenon happens. But for me on OSX 10.5 it is like this: when dsp is turned on, then off again, and the computer is put to sleep mode and waked up again, metro will instantaneously count all it's lost ticks. However, it does not happen with dsp on while going in sleep mode, and also it does not happen when dsp is still "off" after Pd startup. (Is DSP really off at startup?).
I tried these things with Pd extended 0.41 but also with the latest build of 0.42.5-extended-rc1. The behaviour is the same for both versions, as far as I can see.
I should better include the patch which I used to check these things.
#N canvas 628 67 463 505 10;
#X obj 98 198 metro 1000;
#X obj 98 250 +;
#X msg 98 223 1;
#X floatatom 98 278 5 0 0 0 - - -;
#X obj 98 173 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X msg 51 223 0;
#X text 11 222 reset;
#X msg 10 111 \; pd dsp 1;
#X obj 10 52 loadbang;
#X obj 77 87 delay 1000;
#X msg 77 111 \; pd dsp 0;
#X text 10 12 patch for testing sleep behaviour of [metro];
#X text 148 119 1: make sure DSP is turned on and then off.;
#X text 132 172 2: activate metro.;
#X text 135 279 3: watch seconds being counted in normal conditions
;
#X text 13 320 4: put your computer to sleep for a couple of minutes.
;
#X text 13 349 5: wake up your computer and watch the seconds-counting
box. Metro will probably execute all the ticks which it missed while
sleeping. This can cause considerable CPU load \, up to 100%. After
a couple of hours of sleep and with a faster metro speed \, CPU overload
may last for minutes.;
#X text 14 430 6: reset counter \, turn DSP on and do sleep - wake
up again. Probably you will find that the abovementioned behaviour
does not happen now.;
#X connect 0 0 2 0;
#X connect 1 0 3 0;
#X connect 2 0 1 0;
#X connect 3 0 1 1;
#X connect 4 0 0 0;
#X connect 5 0 1 1;
#X connect 5 0 1 0;
#X connect 8 0 7 0;
#X connect 8 0 9 0;
#X connect 9 0 10 0;