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
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:
- 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
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:
- 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
Here's the cleaned-up and hopefully final version with a couple more improvements and bugfixes. Sorry for the barrage of sloppy patches...
-
Ivica Ico Bukvic