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