In hope to answer some of the questions I presented on the pd-list the other day, attached is the patch (diff -u against pd-extended svn 0.42.5) that converts miXed/cyclone/coll.c object into a threaded version which in turn does not trigger xruns every time one tries to open or save a file at runtime. This is particularly apparent when opening/closing large files using low latency audio buffers. This problem is also apparent in other similar objects (e.g. msgfile) and should be ostensibly solvable using the same principle.
Additional lessons I learned from this exercise and am sharing them here in hope others may benefit from them as well are as follows:
- Spawning a secondary thread within an external (detached or not)
should in principle never result in an xrun, except in the coll object I discovered that always the first thread creation did result in an xrun which is why the code also does a bogus thread immediately following the creation time using clock_delay. I am not sure whether this is atom-CPU-specific or more widespread and/or whether this has to do with the way PD is designed. Any thoughts are most appreciated here.
- Triggering clock_delay from a separate thread works fine and should
be always used (rather than dealing with the outlet traffic directly) to prevent out-of-sync gui operations which may result in gui freezing/crashing.
Cheers!
Ico