Pall Thayer kennari/myndlistamaður artist/teacher Fjolbrautaskolinn vid Armula (www.fa.is) http://www.this.is/pallit http://www.this.is/pallit/isjs http://www.this.is/pallit/harmony
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
I just can't figure this one out. I've got a linux machine that's been running two seperate pd patches for the past 3 or 4 months with no problems. When I look at 'top' I see that each of them (they're running as seperate instances of pd with no gui, somewhere in the background) are using from 2 to 8 percent of the cpu. Now I'm working on adding a third one, it's actually not much different than the first one but when I run it, it uses 50 to 70 percent of the cpu! Both of these patches, the 1st and 3rd, are running two seperate sequencers, a mixture of some other minor stuff and sending the whole shebang to an icecast Mp3 server. But the two sequencers are created quite differently. In the new one (the one that eats up the cpu) I step through arrays for the sequences. On the first one, I didn't know how to use arrays and managed to create a very complicated system that looks like it MUST do more than play an eight step sequence (but it doesn't). Anyway, when I figured out the arrays I thought, "Hey, that should make it more cpu friendly. But of course, that might not necessarily be the problem. In the new one, I'm also running two envelope followers and the flashserver object. I've gone through and tried removing bits and pieces to see if anything will lighten the load but nothing appears to make any significant difference, not even when I remove the env~ objects. I'm frustrated.
Well, I suspect, this is difficult to solve without seeing the patches. I don't know, how you did it, but I can't imagine, that the array-seqeuencer is faulty here. I use lots of [GUI heavy] sequencers, that store steps in arrays, and they don't have much cpu load (you might look at them at footils.org, the family is called "sseq".) Also env~ isn't that CPU hungry, normally. I don't know flashserver, though.
Frank Barknecht _ ______footils.org__
Hi Frank, Funny you should respond, I also have two buzz~ objects in the patch. Anyway, here's the evil cpu-eating patch. Yes it's a mess, it looks like it wouldn't even patch a bike tire but hey, it does the job.
best regards, Pall
#N canvas 3 -1 986 643 10; #N canvas 0 0 450 300 graph4 0; #X array array100 100 float 1; #A 0 99 5 35 24 37 35 108 108 65 118 116 118 87 87 93 13 92 3 102 4 6 14 13 14 0 0 0 0 12 4 15 11 0 0 5 4 1 9 1 10 13 6 10 9 6 6 13 0 8 8 16 0 9 8 0 7 11 5 84 8 106 9 66 6 6 9 12 13 8 0 5 0 9 0 0 0 4 3 0 14 0 11 0 3 12 12 6 14 14 1 1 6 1 13 15 0 5 11 3 1; #X coords 0 128 128 0 100 50 1; #X restore 602 21 graph; #X floatatom 420 152 5 0 0; #X floatatom 320 146 5 0 0; #X obj 320 164 tabwrite array100; #X obj 434 -46 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 189 42 tabread array100; #X obj 189 21 f; #X obj 260 21 + 1; #X obj 128 76 mtof; #X obj 177 125 *~ 0; #X obj 220 -46 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X obj 220 -27 metro 700; #X obj 63 206 cos~; #X obj 189 63 route 0; #X obj 260 106 line; #X obj 300 68 delay 10; #X msg 307 -67 set $1; #X floatatom 363 -36 5 0 0; #X msg 272 -53 208; #X obj 27 92 line; #X obj 63 111 *~; #X obj 482 112 delread~ palli 300; #X obj 482 172 delwrite~ palli 300; #X floatatom 482 94 5 0 0; #N canvas 0 0 450 300 graph4 0; #X array array101 100 float 1; #A 0 52 51 52 11 58 100 59 47 39 6 113 55 60 59 74 6 100 56 56 93 116 30 56 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0; #X coords 0 128 128 0 100 50 1; #X restore 460 285 graph; #X floatatom 448 467 5 0 0; #X floatatom 356 467 5 0 0; #X obj 460 232 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 185 320 f; #X obj 266 324 + 1; #X obj 185 375 route 0; #X obj 317 457 line; #X obj 317 396 delay 10; #X floatatom 417 366 5 0 0; #X obj 505 425 delwrite~ einar 300; #X obj 417 384 delread~ einar 300; #X msg 460 251 ; array101 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16; #X obj 356 485 tabwrite array101; #X obj 185 341 tabread array101; #X obj 177 243 *~; #X obj 563 412 *~ 0.38; #X obj 27 50 delay 10; #X obj 482 133 *~ 0.4; #X msg 434 -27 ; array100 56 112 63 84 45 106 7 8 9 10 11 12 13 14 15 16; #X obj 128 97 osc~ 0; #X obj 189 84 mtof; #X obj 63 132 +~; #X obj 63 174 *~; #X obj 63 153 *~; #X obj 189 152 osc~ 0.2; #X obj 128 55 line; #X floatatom 307 27 5 0 0; #X msg 385 425 set 0.05 $1; #X obj 457 446 unpack 0 0; #X msg 86 77 0.2; #X obj 795 222 route 1 2; #X obj 378 111 unpack 0 0; #X obj 294 485 *~ 0; #X obj 375 50 / 5; #X msg 300 89 0.15 41.6; #X msg 375 71 set 0.15 $1; #X obj 422 258 / 2; #X obj 385 282 pipe 0; #X obj 482 73 * 1.5; #X obj 417 345 * 1.2; #X obj 39 132 vsl 15 128 0 500 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X msg 59 243 $1 200; #X obj 59 264 line; #X obj 106 223 lop~ 100; #X msg 317 436 0.05 416; #X obj 385 404 * 2; #X msg 128 34 $1 25; #X obj 657 168 buzz~; #X obj 664 125 * 0.1; #X floatatom 716 43 5 0 0; #X obj 717 121 * 0.1; #X floatatom 740 152 5 0 0; #X obj 740 170 * 0.1; #X obj 717 100 line; #X msg 27 71 4 250; #X obj 5 383 env~ 10000; #X obj 128 13 - 24; #X obj 320 125 pipe 2; #X obj 385 446 pipe 2; #X obj 511 -53 route 1 2 3 4; #X obj 254 277 route 1 2 3 4; #X obj 59 425 env~ 10000; #X obj 227 412 buzz~; #X obj 247 383 * 0.1; #X obj 97 396 mtof; #X floatatom 118 446 5 0 0; #X obj 119 520 * 0.1; #X obj 119 499 line; #X obj 173 414 vsl 15 128 1 50 0 0 empty empty empty 0 -8 0 8 -262144 -1 -1 0 1; #X obj 227 454 *~; #X msg 118 464 $1 400; #X obj 97 375 line; #X msg 97 354 $1 70; #X obj 97 417 osc~ 0; #X obj 141 354 mtof; #X msg 716 61 $1 300; #X obj 214 21 mod 16; #X obj 5 404 dbtorms; #X obj 5 425 * 10; #X obj 5 446 i; #X obj 317 417 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X obj 291 396 bng 15 250 50 0 empty empty empty 0 -6 0 8 -262144 -1 -1; #X msg 260 85 0.3; #X obj 213 324 mod 16; #X obj 227 433 *~ 0.15; #X msg 291 432 0.3; #X obj 629 198 *~ 0.2; #X obj 5 467 * 50; #X obj 59 446 dbtorms; #X obj 59 467 * 10; #X obj 59 488 i; #X obj 59 509 * 50; #X msg 664 104 16; #X msg 247 362 8; #X obj 74 -36 loadbang; #X obj 141 320 - 24; #X obj 657 489 mp3cast~; #X msg 668 412 mpeg 32000 32 3 5; #X msg 676 439 mountpoint icy_2; #X msg 655 389 connect localhost 8000; #X msg 681 467 passwd nonb3; #X obj 718 316 loadbang; #X obj 718 337 delay 5; #X obj 718 370 delay 5; #X msg 792 152 broadcast lseq1 $1; #X msg 785 174 broadcast lseq2 $1; #X msg 802 131 broadcast midis1 $1; #X obj 185 294 metro 350; #X obj 785 197 flashserver 8765 150; #X connect 1 0 3 1; #X connect 2 0 3 0; #X connect 4 0 43 0; #X connect 5 0 13 0; #X connect 6 0 7 0; #X connect 6 0 5 0; #X connect 7 0 101 0; #X connect 8 0 44 0; #X connect 9 0 22 0; #X connect 9 0 121 0; #X connect 10 0 11 0; #X connect 10 0 132 0; #X connect 11 0 6 0; #X connect 12 0 68 0; #X connect 13 1 15 0; #X connect 13 1 107 0; #X connect 13 1 54 0; #X connect 13 1 41 0; #X connect 13 1 81 0; #X connect 13 1 131 0; #X connect 14 0 9 1; #X connect 15 0 59 0; #X connect 16 0 18 0; #X connect 17 0 16 0; #X connect 18 0 11 1; #X connect 18 0 58 0; #X connect 18 0 61 0; #X connect 18 0 62 0; #X connect 18 0 63 0; #X connect 18 0 64 0; #X connect 19 0 20 0; #X connect 20 0 46 0; #X connect 21 0 42 0; #X connect 23 0 21 0; #X connect 25 0 37 1; #X connect 26 0 37 0; #X connect 27 0 36 0; #X connect 28 0 29 0; #X connect 28 0 38 0; #X connect 29 0 108 0; #X connect 30 1 32 0; #X connect 30 1 106 0; #X connect 30 1 120 0; #X connect 31 0 57 1; #X connect 32 0 105 0; #X connect 33 0 35 0; #X connect 35 0 40 0; #X connect 38 0 30 0; #X connect 39 0 9 0; #X connect 39 0 80 0; #X connect 40 0 34 0; #X connect 40 0 121 0; #X connect 41 0 79 0; #X connect 42 0 22 0; #X connect 42 0 121 0; #X connect 44 0 48 1; #X connect 44 0 20 1; #X connect 45 0 49 0; #X connect 45 0 72 0; #X connect 46 0 48 0; #X connect 47 0 12 0; #X connect 48 0 47 0; #X connect 48 0 47 1; #X connect 49 0 39 1; #X connect 49 0 46 1; #X connect 50 0 8 0; #X connect 50 0 45 0; #X connect 51 0 101 1; #X connect 52 0 69 0; #X connect 53 0 83 0; #X connect 53 1 25 0; #X connect 54 0 19 0; #X connect 55 0 84 0; #X connect 55 1 85 0; #X connect 56 0 82 0; #X connect 56 1 1 0; #X connect 57 0 34 0; #X connect 57 0 86 0; #X connect 57 0 121 0; #X connect 58 0 60 0; #X connect 59 0 14 0; #X connect 60 0 59 0; #X connect 61 0 62 1; #X connect 61 0 132 1; #X connect 62 0 70 0; #X connect 63 0 23 0; #X connect 64 0 33 0; #X connect 65 0 66 0; #X connect 66 0 67 0; #X connect 67 0 68 1; #X connect 68 0 39 0; #X connect 69 0 31 0; #X connect 70 0 52 0; #X connect 71 0 50 0; #X connect 72 0 111 0; #X connect 73 0 72 2; #X connect 74 0 100 0; #X connect 75 0 72 3; #X connect 76 0 77 0; #X connect 77 0 72 1; #X connect 78 0 75 0; #X connect 79 0 19 0; #X connect 80 0 102 0; #X connect 81 0 71 0; #X connect 82 0 2 0; #X connect 83 0 26 0; #X connect 84 0 17 0; #X connect 84 1 51 0; #X connect 84 2 56 0; #X connect 84 3 74 0; #X connect 85 2 53 0; #X connect 86 0 113 0; #X connect 87 0 109 0; #X connect 88 0 87 2; #X connect 89 0 98 0; #X connect 90 0 95 0; #X connect 91 0 87 3; #X connect 92 0 91 0; #X connect 93 0 90 0; #X connect 94 0 57 0; #X connect 95 0 92 0; #X connect 96 0 89 0; #X connect 97 0 96 0; #X connect 98 0 94 1; #X connect 98 0 57 0; #X connect 99 0 87 0; #X connect 100 0 78 0; #X connect 101 0 6 1; #X connect 102 0 103 0; #X connect 103 0 104 0; #X connect 104 0 112 0; #X connect 105 0 69 0; #X connect 106 0 110 0; #X connect 107 0 14 0; #X connect 108 0 28 1; #X connect 109 0 94 0; #X connect 109 0 34 0; #X connect 110 0 31 0; #X connect 111 0 22 0; #X connect 111 0 121 0; #X connect 112 0 129 0; #X connect 113 0 114 0; #X connect 114 0 115 0; #X connect 115 0 116 0; #X connect 116 0 130 0; #X connect 117 0 73 0; #X connect 118 0 88 0; #X connect 119 0 10 0; #X connect 119 0 18 0; #X connect 119 0 117 0; #X connect 119 0 118 0; #X connect 120 0 97 0; #X connect 120 0 99 0; #X connect 122 0 121 0; #X connect 123 0 121 0; #X connect 124 0 121 0; #X connect 125 0 121 0; #X connect 126 0 125 0; #X connect 126 0 123 0; #X connect 126 0 127 0; #X connect 127 0 122 0; #X connect 127 0 128 0; #X connect 128 0 124 0; #X connect 129 0 133 0; #X conne ct 130 0 133 0; #X connect 131 0 133 0; #X connect 132 0 28 0; #X connect 133 0 55 0;
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
Funny you should respond, I also have two buzz~ objects in the patch.
Ah, buzz~ *can* eat a lot of CPU, because it's not very efficient, it calls sin() directly 2 times each dsp cycle. But this should normally be okay, unless you put a lot, say more than about 5 buzz~es into your patch, depending on the host CPU. But you probably already tested removing the buzz~ or replacing with phasor or such?
Anyway, here's the evil cpu-eating patch. Yes it's a mess, it looks like it wouldn't even patch a bike tire but hey, it does the job.
Well, you start with -nogui anyways, don't you?
Looking at and running your patch, I can't see what's wrong. Here, on a Athlon 900 MHz it doesn't eat CPU at all, so it seems. I don't have the flashserver. I rellay don't see anything suspicious ;(
Frank Barknecht _ ______footils.org__
Hi Frank, I only have two buzz~es in there and yes I have tried removing them. I run the patch with -nogui and -nosound because I don't need to send it out the soundcard anyway, and I run it on a 400 Mhz Celeron machine with Redhat 7.3. I'll check the Flashserver again. Anyway, thanks for your help.
Pall
----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.kug.ac.at Sent: Saturday, January 11, 2003 1:46 AM Subject: Re: [PD] cpu load question
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
Funny you should respond, I also have two buzz~ objects in the patch.
Ah, buzz~ *can* eat a lot of CPU, because it's not very efficient, it calls sin() directly 2 times each dsp cycle. But this should normally be okay, unless you put a lot, say more than about 5 buzz~es into your patch, depending on the host CPU. But you probably already tested removing the buzz~ or replacing with phasor or such?
Anyway, here's the evil cpu-eating patch. Yes it's a mess, it looks like
it
wouldn't even patch a bike tire but hey, it does the job.
Well, you start with -nogui anyways, don't you?
Looking at and running your patch, I can't see what's wrong. Here, on a Athlon 900 MHz it doesn't eat CPU at all, so it seems. I don't have the flashserver. I rellay don't see anything suspicious ;(
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Pall Thayer schrieb:
I'll check the Flashserver again.
Hi Pall,
I've used flashserver and 18 shoutcast~s streaming to icecast server in one single pd patch on a 1.8GHz machine (Win2k) without any problem. Okay, I have to admid that I had PD running at 24kHz sample rate. In general fashserver is just a modified netreceive, so I don't see why it should eat a lot of CPU....
Olaf
Hi Olaf, p.s. Thanks for all the cool externals! I'm running PD at 32kHz. My first thought was that I had forgotten to set the sampling rate when I started PD up because I'm encoding the stream at 32000, but I've checked again and again and that's not the problem. Weird. Pall
----- Original Message ----- From: "Olaf Matthes" olaf.matthes@gmx.de To: "Pall Thayer" pall@fa.is; "pd-list" pd-list@iem.kug.ac.at Sent: Saturday, January 11, 2003 2:54 AM Subject: Re: [PD] cpu load question
Pall Thayer schrieb:
I'll check the Flashserver again.
Hi Pall,
I've used flashserver and 18 shoutcast~s streaming to icecast server in
one
single pd patch on a 1.8GHz machine (Win2k) without any problem. Okay, I
have to
admid that I had PD running at 24kHz sample rate. In general fashserver is
just
a modified netreceive, so I don't see why it should eat a lot of CPU....
Olaf
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
Anyway, here's the evil cpu-eating patch. Yes it's a mess, it looks like it wouldn't even patch a bike tire but hey, it does the job.
Okay, I found and installed mp3cast and flashserver now, but still nothing unusual in the patch. Strange.
Frank Barknecht _ ______footils.org__
What does your machine show when you do commandline top with the patch running?
----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.kug.ac.at Sent: Saturday, January 11, 2003 1:53 AM Subject: Re: [PD] cpu load question
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
Anyway, here's the evil cpu-eating patch. Yes it's a mess, it looks like
it
wouldn't even patch a bike tire but hey, it does the job.
Okay, I found and installed mp3cast and flashserver now, but still nothing unusual in the patch. Strange.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
What does your machine show when you do commandline top with the patch running?
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 8476 freak 9 0 3020 3016 1592 S 0.0 1.1 0:00 pd
That's not much. But I don't have icecast here (yet), so the mp3cast~ is running empty...
Frank Barknecht _ ______footils.org__
Ok, I've been doing alot of poking around and this is what I've found out. I have three seperate patches running simultaneously on the same machine. It appears that when I run only patch 1 and patch 2, everything's ok. Also, if I run patch 1 and patch 3, everything's ok. However, if I run patch 2 and patch 3, cpu use goes way up and it's not always the same. Sometimes, both patches show a huge increase in cpu use (about 18% each) and other times patch 2 remains the same but patch three uses about 50%.
And here's a new twist, I tried running them on another machine with an identical setup except it has a 600 mhz celeron instead of 400 (on the 'problem' machine) and everything was fine. They were all running at 0%.
Any ideas? Anyone?
best regards, Pall
----- Original Message ----- From: "Pall Thayer" pall@fa.is To: pd-list@iem.kug.ac.at Sent: Saturday, January 11, 2003 10:39 AM Subject: Re: [PD] cpu load question
What does your machine show when you do commandline top with the patch running?
----- Original Message ----- From: "Frank Barknecht" fbar@footils.org To: pd-list@iem.kug.ac.at Sent: Saturday, January 11, 2003 1:53 AM Subject: Re: [PD] cpu load question
Hi, Pall Thayer hat gesagt: // Pall Thayer wrote:
Anyway, here's the evil cpu-eating patch. Yes it's a mess, it looks
like
it
wouldn't even patch a bike tire but hey, it does the job.
Okay, I found and installed mp3cast and flashserver now, but still nothing unusual in the patch. Strange.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list