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.