[PD] dropout problems (#1 solved)
Matteo Sisti Sette
matteosistisette at gmail.com
Sun May 18 12:54:56 CEST 2008
> 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:
1) 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
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).
More information about the Pd-list