So, I looked further into msgfile and coll and found out whenever they try to do file i/o on files with moderate number of lines (or greater), e.g. 500+ lines, there is a guaranteed xrun when Pd is running with a small internal audio buffer (FWIW, all this has been observed on an atom computer where likely high cpu load threshold is more easily tripped and thus these problems are perhaps more apparent). Consequently this makes me wonder if it may be a good idea to adapt one of these objects so that they do file i/o in a separate thread?
This brings me to my second question. Mrpeach tcpserver with recently submitted patches wraps broadcast call into a separate thread which is terminated as soon as a particular task is complete. One would think that this kind of a design should be better in terms of preventing audio xruns. Yet, in practice I've discovered that it still causes xruns fairly regularly, particularly when the computer is under load. OTOH, the disis_wiimote object developed as part of the L2Ork project which maintains a persistent secondary thread for triggering rumble and LED toggle calls to the wiimote never trips an xrun, no matter what the workload. By now you are probably wondering what is my question. Actually there are several: 1) If tcpserver's "spawn a secondary thread, execute, terminate secondary thread" is causing xruns but disis_wiimote's persistent secondary thread with mutex does not, does this mean that spawning threads is so taxing on the computer so as to cause the aforesaid xruns thus defeating the very advantage one is trying to generate by spawning them? 2) If answer to #1 is yes, is this because tcpserver's thread is one that detaches from the main thread? 3) if answer #2 is yes, is there anything one can do to lower the overhead of this breakaway thread? 4) could one ostensibly use persistent thread model from disis_wiimote on coll and/or msgfile in order to abate file i/o xruns? 5) if answer to #4 is yes, could the secondary thread call clock_delay()to provide a bang-on-read-complete (as the coll does) even though it is effectively running independently from the main thread without causing a major ruckus inside Pd's internal interrupt/clock that deals with audio and gui updates? Any help is most appreciated. Ivica Ico Bukvic, D.M.A. Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Dept. of Music - 0240 Blacksburg, VA 24061 (540) 231-6139 (540) 231-5034 (fax) i...@vt.edu http://www.music.vt.edu/faculty/bukvic/ _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
