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:
- 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.
Maybe is not a PD problem, generally is a Windows problem, try ASIO drivers [1]. It happened to me too.
_Ricardo
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:
- 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
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:
- 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
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
@matteo: 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?
You're right I didn't mention it. It happens with a few more patches (patch-pairs indeed) which have a similar architecture and use a lot of the same abstractions as these.
However it doesn't happen with EVERY patch.
Two things make me think it is somewhat memory-related or quantity-related:
- I could reproduce it even with some built-from-scratch patch, though not
systematically (otherwise I would have posted some test patch) 2) If I remove 90% of things from the original offending patches, I get much less dropouts (still some)
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.
Of course I don't assume PD alone is the source of the problem. I'm trying to figure out.
It's not strictly patch related, but it happens with a certain "class" of patches, and I'm not sure whether it is: 1 - patches that use much memory 2 - two instances of PD 2 bis - two instances of PD connected with netsend/netreceive in both directions (not necessarily actively sending and surely not generating loops) 3 - patches with a lot of objects 4 - patches with many many instances of the same abstraction 5 - patches with many levels of nesting of abstractions
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.
I think in my case ther may be a link between activity (either of the patch or of the system in general, stealing resources from PD) and the FIRST FEW dropouts, but then the dropouts go on forever, as if PD couldn't "recover".
I am a complete analphabet about "low-level" programming mechanics, so I may speak nonsense now. I guess PD does some kind of "best effort" to avoid dropouts.... trying to request resources when he needs them and releasing them only when there's no risk (as far as the operating system allows obviously).... is it possible that there is some "instability" of these mechanisms such that, when a dropout condition occurs (or a burst of them), it becomes much more dropout-prone than necessary in the future?? Just to make an analogy: imagine you have a buffer and you're forgetting to refill it as much as you can when the input speed exceeds the output speed: you will get a buffer underrun that could be avoided.
I will try the ASIO suggestion however, since I MAY be using asio drivers on the non-dropping-out mahcine and non-asio in the dropping-out machine!!! (don't have them here and can't check right now).
Thanks m.
-
Matteo Sisti Sette -
Ricardo Dueñas Parada -
Roman Haefeli