[PD] dropout problems (#1 solved)

[Roman Haefeli]

hi all

i could get rid of the drop out issues here :-D

short history:
because i guessed, it could be memory related (the working box has 1.5GB
RAM and the drop-out box only 0.5GB), i put all memory that i could find
into the drop-out box.  then i realized, that i am using two different
versions of [partconv~] on each box and installed the old version (0.1)
on the dropout box, which improved the situation, but i still had
drop-outs. then i decided to remove the additional RAM again, because i
took it from another box and it seemed, that the amount of RAM doesn't
affect the result. however, i noticed, that the additional RAM was much
slower (266MHz), whereas the original RAM and the bus runs usually at
400MHz (from what i could find out by googling the box and the type of
RAM, that was originally built-in). 
after removing the additional RAM blocks again, i didn't have any
drop-outs at all anymore on the drop-out box. it seems, that in my case
the speed, at which memory could be read, was the bottle neck. this also
fits together with my previous assumption, that switching tables with
[partconv~] at high rates is the cause of the trouble.
i couldn't figure out, though, why the old [partconv~] version 0.1 works
better in my case than the current svn version. the main difference,
that i was able to notice, is that the new partconv~.c is much bigger.


@matteo:
your problem seems to be much weirder, because you even get drop-outs,
when there is no activity. in my case there was at least a link between
activity (sending 'set' messages to [partconv~]) and drop-outs.
most likely you already tested it, but you didn't tell anything about
it: on the drop-out machine, do you also get drop-outs with other
patches? or is it clearly related to this particular pair of patches,
that you mentioned? i mean, if it is not patch related (as it was in my
case), then probably not pd alone is the source of the problem (as
ricardo suggested in a previous post), but something with your
pd-driver-soundcard setup in general. 

yo.. thanks to all of you for your suggestions. 

roman


On Sun, 2008-05-18 at 00:18 +0200, Matteo Sisti Sette wrote:
> 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


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de