Maybe is not a PD problem, generally is a Windows problem, try ASIO drivers [1]. It happened to me too.
[1] http://www.asio4all.com/ _Ricardo 2008/5/17 Matteo Sisti Sette <[EMAIL PROTECTED]>: > 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: > > 1) 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. > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
