I sent this from the wrong address so I re-send it. In case it reaches the list twice I apologize.
Hi,
Curiously enough, I am having CRAZY and inexplicable dropout problems too (but on windows). I've described them in a previous thread, and I have no idea whether there may be any relation between my dropout problems and yours.
However, there are some similarities:
- I also use two instances of PD: one generating audio (with dsp turned
on), and the other one for only GUI, with dsp turned off. In my case both are PD-Vanilla. 2) They communicate with each other with netsend/netreceive 3) Cpu usage is very low (much lower than yours); even with near to 0% cpu usage (on both pd instances) I get dropouts 4) The quantity of messages being sent through netsend/netreceive cannot justify dropouts: in your case it cannot because the rate of messages is fixed and you get dropouts only in some cases; in my case, it cannot justify because even when NO data is being transmitted in either direction, I get dropouts 5) This happens on one machine and doesn't happen on another machine, both windows xp with the same version of pd (vanilla 0.41-3) and with the same patches. Both machines are very similar (two laptops from the same vendor and almost same model) and the non-dropout one does NOT have faster CPU (though not slower either) - the only difference I can tell is the non-dropout one has more RAM: 2GB vs one
In my case, both the audio-generating patch and the GUI-only patch are very "big", i.e. use much memory (lots of objects containing losts of instances of lots of abstractions, etc) BUT they are doing _really_ almost nothing when I still get dropouts. All idle audio abstractions/subpatches are always switch~ed off.
The audio patch has a lot of tables, into which I load a lot of audio data _at the beginning_ so that uses a lot of memory too - however, even if I DON'T load audio data (so I do have a lot of tables but they are all very small and use much less memory) I equally experience dropouts - on one machine.
My only suspects/guesses A) some memory issue (though using around 100-200 MB memory on a 1GB machine shouldn't justify persistent memory trashing generating many dropouts per second forever) B) some issue with "big quantity of things", that is: "things which PD does" every once in a while even when the patch is not doing nothing, and which take O(f(N)) time where N is the number of total objects (or total whatever) and f(N) is an increasing function? C) some bug in netsend/netreceive "silently" communicating with each other even when the patches are not sending anything?? D) some kind of unexpected interference between multiple instances of PD????
Are B-D absolute nonsense?
Probably my issue and yours are unrelated, but I was very surprised to read another case of unexplicable dropouts and to note the coincidences (especially 2 instances of PD running and communicating).
Andy Farnell mentioned [line] and I assume he meant what he said, i.e. [line] and not [line~]. I may have more than a few [line] objects around but they are absolutely "idle" (as far as I'm responsible) while I get dropouts (i.e. not receiving input nor producing output). Same goes for [line~]s that are even switched~ off.
I test it by listening to an [osc~ 500] when EVERYTHING else is doing absolutely nothing in both patches and I get dropouts.
Often (not always), dropouts begin when one may reasonably expect to get a short burts of dropouts: for example minimizing and maximizing a patch window full of GUI (note however that I do this on the pd instance that is NOT generating audio... however this may "steal" cpu to the other instance for a while) - but then they never ever end!!!
Well.... any clues about Roman's problem may be of interest to me too!!!
Thanks m.