[PD] continuous dropouts in windows, probably memory issue
matteo sisti sette
matteosistisette at gmail.com
Wed Apr 30 14:41:45 CEST 2008
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):
-virtual memory size
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
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
Hope someone can help...
2008/4/28 Hans-Christoph Steiner <hans at 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
> 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 at gmail.com
> > http://www.matteosistisette.com
> > _______________________________________________
> > PD-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> kill your television
Matteo Sisti Sette
matteosistisette at gmail.com
More information about the Pd-list