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

Ivica Ico Bukvic ico at vt.edu
Sun Sep 26 19:25:23 CEST 2010


All right, third time is a charm. This time implementation uses
persistent thread and safer mutex approach, as well as cleaner code.
Spawning and detaching threads in the previous iteration has
inexplicably caused considerable tear in pd<->gui communication. If
anyone has any explanation why that would be I would greatly appreciate
your feedback.

Best wishes,

Ico

On Sat, 2010-09-25 at 20:05 -0400, Ivica Ico Bukvic wrote:
> 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: 28452 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20100926/ab297b52/attachment-0001.bin>


More information about the Pd-list mailing list