[PD] xrun-free file i/o using the coll external (SOLVED)

[Ivica Ico Bukvic]

Oops, please use the attached patch instead.

Best wishes,

Ico

On Sat, 2010-09-25 at 12:36 -0400, Ivica Ico Bukvic wrote:
> 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:
> 
> 1) 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.
> 
> 2) 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: coll.patch
Type: text/x-patch
Size: 31549 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100925/ab9571f7/attachment-0001.bin>