<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>
      <blockquote type="cite">
        <p>Note that [seek( could block as well, so we would have to<br>
        </p>
        <p>1) stop playback</p>
        <p>2) [seek(</p>
        <p>3) start playback after some delay</p>
      </blockquote>
      On a second thought, this is not really true. When you seek to a
      new position, there should still be data in the read buffer (just
      like when playing sequentially). If not, it means that you would
      have to increase the read buffer size.</p>
    <p>So it seems like a [seek( method would be an overall improvement
      to [readsf~]. I might give it a shot next week.</p>
    <p>Christof<br>
    </p>
    <div class="moz-cite-prefix">On 11.09.2021 02:53, Christof Ressi
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:ec4571cd-2b6b-d04f-3742-39b61b7060c4@christofressi.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p>Here's some more background info:</p>
      <p>If [readsf~] notices that the read buffer is empty, it doesn't
        just output silence, instead it signals the I/O thread and waits
        until data is available. This means that the outpout of
        [readsf~] is always deterministic!</p>
      <p>Now, if you call [1( right after [open(, the read buffer might
        still be empty on the next call of the perform routine, so
        [readsf~] can block for some time.<br>
      </p>
      <p>I have added some debugging statements in the [readsf~] code to
        check when and how long the perform routine blocks.</p>
      <p>First I use <a class="moz-txt-link-freetext"
          href="https://docs.microsoft.com/de-de/sysinternals/downloads/rammap"
          moz-do-not-send="true">https://docs.microsoft.com/de-de/sysinternals/downloads/rammap</a>
        to clear the file cache. Then I try to play a soundfile
        repeatedly without delay between [open( and [1(. These are the
        results:<br>
      </p>
      <p>readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 5.931837 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.007390 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.169551 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.008211 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.129729 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.014779 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.137119 ms<br>
        readsf~: wait...<br>
        readsf~: ... done<br>
        readsf~ blocked for 0.034896 ms</p>
      <p>Initially the file is not cached and Pd blocks for about 6 ms,
        but subsequent reads only block for a fraction of a
        milliseconds.</p>
      <p>But as IOhannes has pointed, this is very dependent on your OS,
        the size of the file and the overall state of the file cache.
        Often you can get away with reopening the file without delay,
        but it is not 100% safe, so you should better add a [delay]. If
        you want to loop without gaps, you can actually use two
        [readsf~] objects and call [1( and [open( alternately.</p>
      <p>---<br>
      </p>
      <p>By the way, the help patch for [readsf~] really needs to be
        updated. It currently says:</p>
      <p> </p>
      <blockquote type="cite">You must open the soundfile in advance (a
        couple of seconds before you'll need it) using the "open"
        message.</blockquote>
      This should really be "a couple of milliseconds". Also, we could
      add "... otherwise Pd might block" to make clear what happens.<br>
      <p>---</p>
      <p>As a side note: it would be great if [readsf~] had something
        like a [seek( method, where you can seek to a specific sample
        onset. It's already possible with [open(, but it's a bit
        cumbersome and it would unnecessarily reopen the file.</p>
      <p>Note that [seek( could block as well, so we would have to<br>
      </p>
      <p>1) stop playback</p>
      <p>2) [seek(</p>
      <p>3) start playback after some delay<br>
      </p>
      <p>Also, [readsf~] could have a "non-blocking" mode which would
        just output zeros as long as the buffer is empty - instead of
        blocking Pd. Playback would be undeterministic, but in many
        scenarios this is not an issue. Looping would be as simple as
        connecting the right outlet of [readsf~] to [seek 0(.<br>
      </p>
      <p>Christof<br>
      </p>
      <br>
      <div class="moz-cite-prefix">On 10.09.2021 17:18, IOhannes m
        zmoelnig wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:a8ac2bf0-95b2-4abd-3149-94ddfa1f76bf@iem.at">On
        9/10/21 8:37 AM, Simon Iten wrote: <br>
        <blockquote type="cite">hi there, <br>
          <br>
          I am finding conflicting (unclear) info on readsf~ behaviour.
          I want to <br>
          loop a long 8 channel wave file. <br>
          here are my questions: <br>
          <br>
          -once i open the file with a message and after a delay start
          playback and <br>
          it has finished (rightmost outlet bangs), can i restart
          playback without <br>
          delay ([t b b] to open and 1 for start) or do I have to set a
          delay again? <br>
          (will the buffer somehow be ready faster) <br>
        </blockquote>
        <br>
        that depends on your OS. most likely the file will be cached, so
        sequential opens should be fast (but this of course depends on
        how large the file actually is). <br>
        <br>
        a 8-channel soundfile with 15minutes data and 16bit samples will
        have about 600MB at 44kHz. <br>
        that probably should be OK to cache (but then: do you have other
        largish datasets that are loaded as well?) <br>
        <br>
        <blockquote type="cite"> <br>
          -if above is not possible, what happens if the open message is
          sent 15 <br>
          minutes before the 1 message to start playback, are there any
          downsides? <br>
          the fact that I can set a buffer size seems to suggest that
          that buffer <br>
          will simply be filled and after that it waits for the playback
          to start. </blockquote>
        <br>
        that is correct. <br>
        the delay is justa means to give Pd time to fill the buffer. <br>
        once the buffer is filled, Pd will just idle away until it
        starts depleting. <br>
        <br>
        tg,dsr <br>
        IOhannes <br>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at" moz-do-not-send="true">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list" moz-do-not-send="true">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
    </blockquote>
  </body>
</html>