<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1444093982323_4650">1) One thing I noticed is that the article you cited seems to focus<br></div><div id="yui_3_16_0_1_1444093982323_6106" dir="ltr">on tasks not critical to the computation/delivery of audio samples.</div><div id="yui_3_16_0_1_1444093982323_6107" dir="ltr">For example, if your program were blocking or locking in order to do a GUI</div><div id="yui_3_16_0_1_1444093982323_6108" dir="ltr">update. But here, the data must arrive in time to compute the next block. If it</div><div id="yui_3_16_0_1_1444093982323_6109" dir="ltr">takes too long to read the next portion of the sound file, then you're going to get</div><div id="yui_3_16_0_1_1444093982323_6844" dir="ltr">a glitch.</div><div id="yui_3_16_0_1_1444093982323_6160" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_6165" dir="ltr">But I'm not sure I really grasp how locking works, nor really the whole file i/o</div><div id="yui_3_16_0_1_1444093982323_7834" dir="ltr">process in general.<br></div><div id="yui_3_16_0_1_1444093982323_7833" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_7680" dir="ltr">Here's a naive question: why can't you just tell the OS to treat the file as</div><div id="yui_3_16_0_1_1444093982323_7803" dir="ltr">if it were a non-blocking socket, add the fd to Pd's event loop with <br></div><div id="yui_3_16_0_1_1444093982323_7949" dir="ltr">sys_addpollfn, and then receive the incoming data to the relevant function?</div><div id="yui_3_16_0_1_1444093982323_8164" dir="ltr">(Warning: some or all of the above may technically be gibberish...)<br></div><div id="yui_3_16_0_1_1444093982323_8161" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_8162" dir="ltr">-Jonathan<br></div><div id="yui_3_16_0_1_1444093982323_6846" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_6207" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_6208" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_6110" dir="ltr"><br></div><div id="yui_3_16_0_1_1444093982323_6111" dir="ltr"><br></div><br><div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font face="Arial" size="2"> On Monday, October 5, 2015 10:01 PM, Robert Esler <robert@urbanstew.org> wrote:<br> </font> </div> <br><br> <div class="y_msg_container">I’m trying to understand why readsf~ and writesf~ work so well. <br><br>I’m particularly referencing Ross Bencina’s article: <a href="http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing" target="_blank">http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing </a>and his subsequent paper, <a href="http://www.rossbencina.com/static/writings/File_IO_ACMC2014_Bencina.pdf" target="_blank">http://www.rossbencina.com/static/writings/File_IO_ACMC2014_Bencina.pdf</a><br><br>If you are not into asynchronous message passing and lock-free queueing then I’ll summarize the articles briefly: <br><br>When engaging in file I/O (e.g reading from or writing to an audio file) do not use locks or blocking. He goes on to say that this can lead to priority inversion, unbound execution time and “scheduler paranoia”.<br><br>This is all absolutely true in my experience in the audio jungle. <br><br>Pd’s async file I/O objects (readsf~ and writesf~) use both locks and blocking via a mutex and the pthread_cond_signal and pthread_cond_init functions. Look at the source code file d_soundfile.c for more details. The gist of it is that these objects have two threads. One parent thread that sends the data to the dsp scheduler, and a child thread that grabs the data from the file, and subsequently the child signals the parent when it has more data.<br><br>Based on Bencina’s paper, readsf~ and writesf~ could (should?) glitch and may not be real-time safe.<br><br>My questions are:<br><br>1) Have I completely misunderstood d_soundfile.c and it is actually entirely safe. If so, why is it safe?<br><br>2) Why doesn’t Pd glitch more often when using these objects? <br><br>3) Does Pd need lock-free message queueing for such inter-thread communication?<br><br>4) Has anyone ever “broken” these objects or experienced glitching?<br><br>Thanks for the extra brain power.<br>-R<br><br><br><br>_______________________________________________<br><a ymailto="mailto:Pd-list@lists.iem.at" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br><br><br></div> </div> </div> </div></div></body></html>