@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.