2008/5/17 Matteo Sisti Sette <
matteosistisette@gmail.com>:
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.
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list