Hi,
I have (as usual) an enormous patch... "enormous" in terms of quantity of abstractions, levels of nesting, and quantity of objects in each abstraction.
Everything is carefully built in order not to waste CPU. All audio processing objects are swicthed on/off when needed, so that when everything is idle it is consuming 0% cpu; usually only few of the many existing objects are actually playing, so that I never get more than 20-30% cpu usage (on a 2.00GHz dual core, that is approx. 40-60% of a single 2GHz CPU), and only rarely that much. Also, I always avoid generating huge "message trees" that may cause audio dropouts.
The patch occupies about 90Mb in RAM; when all the "samples" (audio files) are loaded, it occupies about 216Mb RAM.
Now, all this used to work perfectly on machine A, and still works perfectly on machine B, where it has been tested under considerable "stress" and has been used on-stage a few times without a single issue.
Machine A and B are almost identical (two laptops from the same vendor), Intel Core Duo 2GHz with windows XP, the only difference is machine A has 1Gb RAM while B has 2Gb RAM. They both have shitty integrated soundcards, and I have tested both with an external MOTU Ultralite Firewire with the same results.
Now, since recently, on machine A the following happens:
I open the patch and it initially works, but as soon as I minimize the patch window and maximize it again (or do a "show desktop" and then focus back on the window, or anything like that), it starts doing audio dropouts: a LOT of dropouts per second, and then it NEVER stops doing dropouts!!!! even if I don't move the window any more, and even when the patch is consuming less than 1% cpu (only playing the 500hz sinewave I use to hear audio dropouts).
This happens even if I never load the samples (that is I don't resize any table and the patch doesn't occupy more than 90Mb.
I have reproduced it even after reducing the patch to less than half its size and removing all tables; however, the quantity of dropouts seems to lower as the patch gets smaller, and when I leave only very few objects in the patch I get no dropouts.
That's why I suspect it is somewhat related to memory usage.
This laptop doesn't have a led indicating disk read/write activity (can you believe it? I'd like to see the face of the guy who designed a laptop and DECIDED that a disk activity led is unnecessary) so I cannot tell whether the system is swapping memory to/from disk when I hear dropouts; however I don't think it can be swapping indefinitely for several minutes while I'm doing nothing..... I can see some memory information in window's Task Manager but it's not very illuminating...
It may be reasonable to expect a few dropouts when you minimize and maximize a window full of GUI when the same patch is producing the sound, but the drop outs should stop after you stop playing around with windows and even touching the mouse and keyboard!! Also, it still happens after removing ALL gui things from the patch.
Is it possible that 1Gb of RAM is just too small for running such a patch? Note that the patch only occupies around 90Mb in memory.
Also, It did work without dropouts in this same machine up to little time ago, and I don't know what can have changed in my system. I had a few troyans, but I got rid of all them.
Any ideas? I'm stuck.....
Thanks in advance m.
In the Task Manager, under the "Processes" tab, you can get more
detailed memory info by turning them on in Edit->Select Columns...
You can get swap activity among other things. Oops, assuming you are
on Windows. Which platform are you on.
If there is a heavy GUI, then there could be a problem with a lot of
communication between the pd and pd-gui processes.
Also, this message is really long. It's best to include a short
summary at the top, then the lengthy details later. More people will
read the message then.
.hc
On Apr 28, 2008, at 6:31 AM, matteo sisti sette wrote:
Hi,
I have (as usual) an enormous patch... "enormous" in terms of quantity of abstractions, levels of nesting, and quantity of objects in each abstraction.
Everything is carefully built in order not to waste CPU. All audio processing objects are swicthed on/off when needed, so that when everything is idle it is consuming 0% cpu; usually only few of the many existing objects are actually playing, so that I never get more than 20-30% cpu usage (on a 2.00GHz dual core, that is approx. 40-60% of a single 2GHz CPU), and only rarely that much. Also, I always avoid generating huge "message trees" that may cause audio dropouts.
The patch occupies about 90Mb in RAM; when all the "samples" (audio files) are loaded, it occupies about 216Mb RAM.
Now, all this used to work perfectly on machine A, and still works perfectly on machine B, where it has been tested under considerable "stress" and has been used on-stage a few times without a single issue.
Machine A and B are almost identical (two laptops from the same vendor), Intel Core Duo 2GHz with windows XP, the only difference is machine A has 1Gb RAM while B has 2Gb RAM. They both have shitty integrated soundcards, and I have tested both with an external MOTU Ultralite Firewire with the same results.
Now, since recently, on machine A the following happens:
I open the patch and it initially works, but as soon as I minimize the patch window and maximize it again (or do a "show desktop" and then focus back on the window, or anything like that), it starts doing audio dropouts: a LOT of dropouts per second, and then it NEVER stops doing dropouts!!!! even if I don't move the window any more, and even when the patch is consuming less than 1% cpu (only playing the 500hz sinewave I use to hear audio dropouts).
This happens even if I never load the samples (that is I don't resize any table and the patch doesn't occupy more than 90Mb.
I have reproduced it even after reducing the patch to less than half its size and removing all tables; however, the quantity of dropouts seems to lower as the patch gets smaller, and when I leave only very few objects in the patch I get no dropouts.
That's why I suspect it is somewhat related to memory usage.
This laptop doesn't have a led indicating disk read/write activity (can you believe it? I'd like to see the face of the guy who designed a laptop and DECIDED that a disk activity led is unnecessary) so I cannot tell whether the system is swapping memory to/from disk when I hear dropouts; however I don't think it can be swapping indefinitely for several minutes while I'm doing nothing..... I can see some memory information in window's Task Manager but it's not very illuminating...
It may be reasonable to expect a few dropouts when you minimize and maximize a window full of GUI when the same patch is producing the sound, but the drop outs should stop after you stop playing around with windows and even touching the mouse and keyboard!! Also, it still happens after removing ALL gui things from the patch.
Is it possible that 1Gb of RAM is just too small for running such a patch? Note that the patch only occupies around 90Mb in memory.
Also, It did work without dropouts in this same machine up to little time ago, and I don't know what can have changed in my system. I had a few troyans, but I got rid of all them.
Any ideas? I'm stuck.....
Thanks in advance m.
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
kill your television
In the Task Manager, under the "Processes" tab, you can get more detailed memory info by turning them on in Edit->Select Columns... You can get swap activity among other things.
Oh thanks, I'll try that out and let you know what I find out.
Oops, assuming you are on Windows.
Yes I am.
If there is a heavy GUI, then there could be a problem with a lot of communication between the pd and pd-gui processes.
This is not the case. I eliminated all the GUI and the problem persists. There is really nothing "going on" in the patch except the oscillator playing a 500Hz sinusoid. Everything else is idle (I mean doing nothing) as far as it depends on me. Nothing is generating messages. Things are just there, and abstraction/subpatches containing dsp stuff are all switched off. If PD is doing something it is doing it on its own initiative.
Also, this message is really long. It's best to include a short summary at the top, then the lengthy details later. More people will read the message then.
Yes you're perfectly right. Thanks for the advice.
Ok I added columns to the task manager but I don't know what I should look for.
The following values of neither the "pd.exe" process DON'T change while I experience dropouts (nor do those of wish84 process):
-memory usage -page faults -virtual memory size -paged pool -I/O read -I/O write -I/O other
The value of "non paged pool" changes every once in a while, but sometimes it stays without changing for a long time while I still hear lots of dropouts per second.
The problem is very difficult to isolate and to reproduce consistently.
-I need a huge patch to reproduce this (even if it is full of objects that are doing absolutely NOTHING) -I don't need to have GUI objects -I don't need to consume much CPU -The only active thing in the patch can be an osc~ and dac~ to hear the dropout. All other dsp things are switch~ed off and nothing is generating any message
-It seems to be triggered when "something happens" in memory: --sometimes it is triggered when I load samples --sometimes, even without loading any sample, I just need to minimize and maximize a window --sometimes, that is not enough to trigger the bug: I need to open a big application such as Flash or Word something
However, the annoying and buggy thing is that even when you remove the reasonable cause of dropouts (when there is one), dropouts don't stop. For example, if it had started doing dropouts when I opened another application, even after closing it, dropouts go on. Even if I close ALL windows except PD and the patch window, and wait a few minutes, the dropouts still go on. If it is loading samples, I know it is OK that I get an audio drop-out when I load a sample, but once the samples are loaded, I keep getting dropouts forever.
Sometimes, after a very very long time that I do nothing (I switch off the oscillator and/or drop my headphones, go out for a walk and come back and the patch is still open, so I wear my headphones again and switch on the oscillator), I find out that dropouts have disappeared.
Once I experienced this: I switched DSP (in main PD window) off and on and dropouts disappeared!! However I couldn't reproduce it any more.
I have the impression that, when some reasonable condition causes a dropout, PD for some reason "can't recover", and keeps doing more dropouts forever or for a long time. I had already experienced this a long time ago when I was indeed "guilty" of causing dropouts (by generating huge amounts of messages in-a-bang, or by too-often refreshing GUI objects.... well wait, the latter was not my fault, that is not supposed to cause dropouts, however it does), and if I created a situation that may generate a dropout at a given instant, PD kept doing dropouts for a few seconds. as if it "couldn't recover".
All this makes PD unstable and unreliable for me, so any help in tracking this down will be very appreciated. At the moment my only workaround is using a PC that has 2GB of RAM, where up to now I haven't had these issues, but I can't be sure I'm "safe" untill I discover the real cause of the problem. Also in the 1GB machine where I do experience dropouts, the problems have begun only recently and neither the patch nor the PD version have changed!! So how can I be sure that one day it will stop working on the other machine!
Hope someone can help...
Thanks m.
2008/4/28 Hans-Christoph Steiner hans@eds.org:
In the Task Manager, under the "Processes" tab, you can get more detailed memory info by turning them on in Edit->Select Columns... You can get swap activity among other things. Oops, assuming you are on Windows. Which platform are you on.
If there is a heavy GUI, then there could be a problem with a lot of communication between the pd and pd-gui processes.
Also, this message is really long. It's best to include a short summary at the top, then the lengthy details later. More people will read the message then.
.hc
On Apr 28, 2008, at 6:31 AM, matteo sisti sette wrote:
Hi,
I have (as usual) an enormous patch... "enormous" in terms of quantity of abstractions, levels of nesting, and quantity of objects in each abstraction.
Everything is carefully built in order not to waste CPU. All audio processing objects are swicthed on/off when needed, so that when everything is idle it is consuming 0% cpu; usually only few of the many existing objects are actually playing, so that I never get more than 20-30% cpu usage (on a 2.00GHz dual core, that is approx. 40-60% of a single 2GHz CPU), and only rarely that much. Also, I always avoid generating huge "message trees" that may cause audio dropouts.
The patch occupies about 90Mb in RAM; when all the "samples" (audio files) are loaded, it occupies about 216Mb RAM.
Now, all this used to work perfectly on machine A, and still works perfectly on machine B, where it has been tested under considerable "stress" and has been used on-stage a few times without a single issue.
Machine A and B are almost identical (two laptops from the same vendor), Intel Core Duo 2GHz with windows XP, the only difference is machine A has 1Gb RAM while B has 2Gb RAM. They both have shitty integrated soundcards, and I have tested both with an external MOTU Ultralite Firewire with the same results.
Now, since recently, on machine A the following happens:
I open the patch and it initially works, but as soon as I minimize the patch window and maximize it again (or do a "show desktop" and then focus back on the window, or anything like that), it starts doing audio dropouts: a LOT of dropouts per second, and then it NEVER stops doing dropouts!!!! even if I don't move the window any more, and even when the patch is consuming less than 1% cpu (only playing the 500hz sinewave I use to hear audio dropouts).
This happens even if I never load the samples (that is I don't resize any table and the patch doesn't occupy more than 90Mb.
I have reproduced it even after reducing the patch to less than half its size and removing all tables; however, the quantity of dropouts seems to lower as the patch gets smaller, and when I leave only very few objects in the patch I get no dropouts.
That's why I suspect it is somewhat related to memory usage.
This laptop doesn't have a led indicating disk read/write activity (can you believe it? I'd like to see the face of the guy who designed a laptop and DECIDED that a disk activity led is unnecessary) so I cannot tell whether the system is swapping memory to/from disk when I hear dropouts; however I don't think it can be swapping indefinitely for several minutes while I'm doing nothing..... I can see some memory information in window's Task Manager but it's not very illuminating...
It may be reasonable to expect a few dropouts when you minimize and maximize a window full of GUI when the same patch is producing the sound, but the drop outs should stop after you stop playing around with windows and even touching the mouse and keyboard!! Also, it still happens after removing ALL gui things from the patch.
Is it possible that 1Gb of RAM is just too small for running such a patch? Note that the patch only occupies around 90Mb in memory.
Also, It did work without dropouts in this same machine up to little time ago, and I don't know what can have changed in my system. I had a few troyans, but I got rid of all them.
Any ideas? I'm stuck.....
Thanks in advance m.
-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
kill your television
-
Hans-Christoph Steiner -
Matteo Sisti Sette -
matteo sisti sette