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.comhttp://www.matteosistisette.com