[PD-dev] xrun-free file i/o using the coll external (SOLVED)
Ivica Ico Bukvic
ico at vt.edu
Sun Sep 26 02:05:05 CEST 2010
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-dev/attachments/20100925/ab9571f7/attachment-0001.bin>
More information about the Pd-dev
mailing list