[PD] dropout problems

[Ricardo Dueñas Parada]

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 <matteosistisette at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080517/5b71577b/attachment.htm>